Closed Bug 1336517 Opened 4 years ago Closed 4 years ago
Issues with bear71
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Flash Version: 18.104.22.168 e10s = false STR 1. Open Nightly and navigate to http://bear71.nfb.ca/#/bear71 2. Watch a couple of videos 3. Grant Flash plugin with access to camera and mic when asked 4. Observe video AR: Flash plugin is crashing ER: Flash plugin should continue playing the video
Stefan, is this win64-specific? This is likely sandbox-related, but you should test to be sure, and also see whether this is a recent regression or dates back to turning the strict plugin sandbox on.
Update: flipping dom.ipc.plugins.asyncdrawing.enable or e10s does not make any difference nor any combination of them. Issues is not reproducible in Nightly 32 bits.
Hardware: Unspecified → x86_64
I'm experiencing a number of issues with 32-bit builds on a slower laptop that I don't see with async drawing turned off: 1) lots of buffering in the video 2) resizing the window doesn't update the dims of the flash applet 3) mouse input is ignored on the video player 4) tab spinner when switching tabs
On my main workstation I have no issues at all.
(In reply to Jim Mathies [:jimm] from comment #3) > I'm experiencing a number of issues with 32-bit builds on a slower laptop > that I don't see with async drawing turned off: > > 1) lots of buffering in the video > 2) resizing the window doesn't update the dims of the flash applet > 3) mouse input is ignored on the video player > 4) tab spinner when switching tabs These are all side effects of a serious performance issue.
milan, can someone on the gfx team who's familiar with the async drawing code poke at this profile? Seems like we're spending a lot of time shifting bits around.
Summary: Allowing Adobe Flash access to Camera and Microphone crash the plugin → Issues with bear71.nfb.ca
Doing a little debugging here, appears the changed information coming in @ NPN_SetCurrentAsyncSurface is ok. If you pause the intro video you get regular updates but those are restricted to the playback status bar. So generally I don't see incorrect data coming from flash.
Flags: needinfo?(milan) → needinfo?(dvander)
David, do you have time to look at this profile? This is a serious performance regression with Flash that is blocking our rollout of 64-bit Firefox as the default install.
The performance regression here is to be expected, I think, given the circumstances. Previously this page was probably getting hardware-accelerated blitting directly onto a window. This is exactly the reason we previously did not force plugins to windowless mode: that involves like four bitmap copies per frame, which is insanely slow compared to windowing. To solve this async drawing introduced two new drawing modes: a faster bitmap mode, and a fast-as-windowed mode using DXGI. For some reason - maybe because the HTML doesn't specify a wmode parameter? This plugin is getting the "faster bitmap" mode. The async bitmap mode is faster than the old windowless mode, but it's still ultimately bitmap copying every frame. There's no way it can compete with acceleration. When I force the site to use wmode="direct", the plugin is as fast as windowed mode again, since it's using the async DXGI path. tl;dr - the plugin is being downgraded to software rendering. We probably have to either convince the site to use wmode="direct", or ask Adobe if it's okay to force this on, maybe on their end or on ours, or on a case-by-case basis.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.