Closed
Bug 1336517
Opened 6 years ago
Closed 6 years ago
Issues with bear71.nfb.ca
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(firefox54 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox54 | --- | affected |
People
(Reporter: StefanG_QA, Unassigned)
References
()
Details
(Keywords: perf)
Attachments
(1 file)
289.04 KB,
image/jpeg
|
Details |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 Flash Version: 24.0.0.194 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
Reporter | ||
Updated•6 years ago
|
OS: Unspecified → Windows
Reporter | ||
Updated•6 years ago
|
OS: Windows → Windows 10
Comment 1•6 years ago
|
||
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.
Flags: needinfo?(stefan.georgiev)
Reporter | ||
Comment 2•6 years ago
|
||
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
Reporter | ||
Updated•6 years ago
|
Flags: needinfo?(stefan.georgiev)
![]() |
||
Updated•6 years ago
|
![]() |
||
Comment 3•6 years ago
|
||
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
![]() |
||
Comment 4•6 years ago
|
||
On my main workstation I have no issues at all.
![]() |
||
Comment 5•6 years ago
|
||
(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.
![]() |
||
Comment 6•6 years ago
|
||
got the crash too - https://crash-stats.mozilla.com/report/index/c28b81e0-8a3a-4752-8ce5-b55c42170207
![]() |
||
Comment 7•6 years ago
|
||
https://clptr.io/2ko7qi5
![]() |
||
Comment 8•6 years ago
|
||
![]() |
||
Comment 9•6 years ago
|
||
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.
Flags: needinfo?(milan)
![]() |
||
Updated•6 years ago
|
Summary: Allowing Adobe Flash access to Camera and Microphone crash the plugin → Issues with bear71.nfb.ca
![]() |
||
Comment 10•6 years ago
|
||
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.
David, does the profile from comment 7 / comment 8 look "expected"?
Flags: needinfo?(milan) → needinfo?(dvander)
Comment 12•6 years ago
|
||
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.
Blocks: support-win64
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.
Flags: needinfo?(dvander)
Updated•6 years ago
|
Blocks: win64-rollout
![]() |
||
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Updated•3 months ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•