flash movie doesn't display, or flashes (!) quickly

RESOLVED FIXED

Status

()

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: shaver, Assigned: cjones)

Tracking

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [hardblocker], URL)

Attachments

(2 attachments)

At the URL above there is a globe below the tipjar, which on some loads doesn't display.  If I click it and come back, it will appear and flash in and out very quickly (30Hz?).  Right-clicking to bring up the Flash context menu slows the flashing to ~2Hz if I had to guess.

I am fully accelerated on Windows 7, NVIDIA driver 8.17.12.6658, Shockwave Flash 10.2 d151.

Ask me anything.
(was in both Feb 16 and Feb 17 builds)

Comment 2

8 years ago
I can reproduce. cjones, can you debug and see what's going on?
Assignee: nobody → jones.chris.g
A flash movie flashes?  Sounds like a WONTFIX to me.
Yeah, easy to repro.  I see it on win7, don't see it on my gtk2 desktop, which is odd.
This happens with GPU rendering forced off on windows, too, so I think it's a bug in the alpha-recovery code for windows in the plugin subprocess.
Correction: happens with d3d10 forced off and d2d on, which is a configuration known to be broken atm (whoops, bye bye that hour).  Basic layers + no-d2d is fine.  Might be a d2d issue somewhere, or might just be a timing thing.
The data points are
 basic + !d2d = OK
 basic +  d2d = buggy
 d3d9  +  d2d = OK
 d3d9  + !d2d = OK
 d3d10 + !d2d = OK
 d3d10 +  d2d = buggy

So the common thread is d2d, which is buggy except in concert with d3d9.  ISTR some synchronization that has to happen between the two, which makes me wonder if we're missing a flush or have some other race condition somewhere.  (Could still be unlucky timing, but that's looking less likely.)

Bas, any ideas?  You might have seem something similar in the past.
(In reply to comment #7)
>  d3d10 + !d2d = OK

(Bas kindly pointed out that this is actually equivalent to "d3d9 + !d2d" since we require d2d for d3d10.  At the least the data points match!)
Bas also helpfully pointed out "a bitmap debugger", and in there with the refresh rate set at 10ms the tool drew one of the buffers smoothly, with the expected animation, while firefox-bin kept drawing with a flicker.  (Cool tool!)  Looks like the surfaces we're getting from the plugin process are OK.

Should be a lot easier for Bas to fix this than me, so reassigning.
Assignee: jones.chris.g → bas.schouten
Assignee: bas.schouten → jones.chris.g
Created attachment 513403 [details] [diff] [review]
Notify the cairo backend that plugin surfaces have changed when swapping

In a nutshell, what appears to have been happening is
 - this page has a plugin inside of a complex clip
 - the Show/Invalidate/GetImage code was working fine, and uploading the right bits to a D3D10 texture
 - BUT, on painting, because of the complex clip, we had to fall back on a temporary layer manager
 - the cairo-d2d backend had cached uploads of the image surfaces and was using those instead of the most recent bits

I'm pretty sure this bug existed before 626602.  We're doing a bunch of dumb things on this page, creating 3 or 4 d3d10 Images with their textures and uploading bits between each paint, but then just end up using a temporary layer manager when painting.  We might want to port lazy uploading of d3d10 Images, like we're doing for d3d9.
Attachment #513403 - Flags: review?
Attachment #513403 - Flags: review? → review?(bas.schouten)
Attachment #513403 - Flags: review?(bas.schouten) → review+
Comment on attachment 513403 [details] [diff] [review]
Notify the cairo backend that plugin surfaces have changed when swapping

This is a regression from 3.6 that's quite ugly, albeit something of an unusual case (complex clip on a plugin).  I certainly wouldn't block betaN on it, but I think we should take it for final.  There's not a lot of risk.
Attachment #513403 - Flags: approval2.0?

Updated

8 years ago
Attachment #513403 - Flags: approval2.0? → approval2.0+
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Whiteboard: [hardblocker] → [hardblocker][needs landing]
Created attachment 513643 [details] [diff] [review]
Notify the cairo backend that plugin surfaces have changed when swapping

Previous patch was missing a null check.
Attachment #513643 - Flags: review+
Keywords: checkin-needed

Updated

8 years ago
Whiteboard: [hardblocker][needs landing] → [hardblocker][needs landing][has patch]
Pushed: http://hg.mozilla.org/mozilla-central/rev/4b0d51f06cda
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Whiteboard: [hardblocker][needs landing][has patch] → [hardblocker]
You need to log in before you can comment on or make changes to this bug.