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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(was in both Feb 16 and Feb 17 builds)

Comment 2

[Benjamin Smedberg]

I can reproduce. cjones, can you debug and see what's going on?

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

A flash movie flashes?  Sounds like a WONTFIX to me.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Yeah, easy to repro.  I see it on win7, don't see it on my gtk2 desktop, which is odd.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(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!)

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: 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.

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Notify the cairo backend that plugin surfaces have changed when swapping

Previous patch was missing a null check.

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Pushed: http://hg.mozilla.org/mozilla-central/rev/4b0d51f06cda