Closed
Bug 635004
Opened 14 years ago
Closed 14 years ago
flash movie doesn't display, or flashes (!) quickly
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(blocking2.0 final+)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: shaver, Assigned: cjones)
References
()
Details
(Whiteboard: [hardblocker])
Attachments
(2 files)
1.28 KB,
patch
|
bas.schouten
:
review+
benjamin
:
approval2.0+
|
Details | Diff | Splinter Review |
1.33 KB,
patch
|
cjones
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•14 years ago
|
||
(was in both Feb 16 and Feb 17 builds)
Comment 2•14 years ago
|
||
I can reproduce. cjones, can you debug and see what's going on?
Assignee: nobody → jones.chris.g
Assignee | ||
Comment 3•14 years ago
|
||
A flash movie flashes? Sounds like a WONTFIX to me.
Assignee | ||
Comment 4•14 years ago
|
||
Yeah, easy to repro. I see it on win7, don't see it on my gtk2 desktop, which is odd.
Assignee | ||
Comment 5•14 years ago
|
||
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.
Assignee | ||
Comment 6•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 years ago
|
||
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.
Assignee | ||
Comment 8•14 years ago
|
||
(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!)
Assignee | ||
Comment 9•14 years ago
|
||
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 | ||
Updated•14 years ago
|
Assignee: bas.schouten → jones.chris.g
Assignee | ||
Comment 10•14 years ago
|
||
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?
Assignee | ||
Updated•14 years ago
|
Attachment #513403 -
Flags: review? → review?(bas.schouten)
Updated•14 years ago
|
Attachment #513403 -
Flags: review?(bas.schouten) → review+
Assignee | ||
Comment 11•14 years ago
|
||
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•14 years ago
|
Attachment #513403 -
Flags: approval2.0? → approval2.0+
Updated•14 years ago
|
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Reporter | ||
Updated•14 years ago
|
Whiteboard: [hardblocker] → [hardblocker][needs landing]
Assignee | ||
Comment 12•14 years ago
|
||
Previous patch was missing a null check.
Attachment #513643 -
Flags: review+
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Updated•14 years ago
|
Whiteboard: [hardblocker][needs landing] → [hardblocker][needs landing][has patch]
Reporter | ||
Comment 13•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [hardblocker][needs landing][has patch] → [hardblocker]
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•