Created attachment 503143 [details] Testcase If hardware acceleration is enabled, MozTransform can draw html elements over Firefox chrome, since the 2010-10-22 nightly. STR: 1) With hardware acceleration enabled, open attached testcase (was taken from bug 622585). 2) Watch element rotate. 3) Repeat steps 1-2 with hardware acceleration disabled & compare. Expected: - HTML element rotates without rendering over Firefox chrome. Actual: - If hardware acceleration enabled: element renders over chrome, if not: renders fine. - See screenshot. Occurs in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110111 Firefox/4.0b10pre ID:20110111030357. Regression range... Last good nightly: 2010-10-21 First bad nightly: 2010-10-22 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4788083ce564&tochange=b6c9c4833613 # Graphics section of about:support # Adapter Description: NVIDIA GeForce 6200 TurboCache(TM) Vendor ID: 10de Device ID: 0161 Adapter RAM: 64 Adapter Drivers: nvd3dumx,nvd3dum Driver Version: 188.8.131.5299 Driver Date: 10-16-2010 Direct2D Enabled: false DirectWrite Enabled: false WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 11 2011 04:14:27) GPU Accelerated Windows: 1/1 Direct3D 9
Suspect changesets in that range perhaps? http://hg.mozilla.org/mozilla-central/rev/73f8c0079bc1 Bug 584494: Avoid creating intermediate surfaces in D3D9 layers. r=roc a=blocking-betaN http://hg.mozilla.org/mozilla-central/rev/598cf02e1c4d Bug 606121. Clip the cached surface in basic layers so we draw only what we need to. r=roc a=joe
blocking2.0: --- → ?
Hoo, that's a bad bug.
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
WFM with D3D10. D3D9 only?
Sounds like a problem in layers clipping.
I think this should be a hardblocker. There are nasty spoofing possibilities here; if we had this bug on a stable branch we'd be fixing it there ASAP...
Yeah, this definitely should be a hardblocker.
Whiteboard: [softblocker] → [hardblocker]
I don't see this on my Win 7 (d3d10) or my Win XP (d3d9) systems. Is this only d3d9 on Win 7?
I'm sorry. I was wrong. I do see this on my WinXP machine with d3d9. So this isn't win7 specific but it is probably d3d 9 specific. (sorry for adding any confusion).
Created attachment 506430 [details] [diff] [review] Properly save and restore old cliprect It turns out that when you set a new render target in D3D9. The scissor rect is set to the bounds of that render target. Therefore we should get the old scissor rect before anything is done to the render target, and restore it after any render target changes back to the original render target have been made.
Created attachment 506431 [details] [diff] [review] Properly save and restore old cliprect v2 Remove debug code from patch.
Comment on attachment 506431 [details] [diff] [review] Properly save and restore old cliprect v2 What code depends on the scissor rect not changing?
Comment on attachment 506431 [details] [diff] [review] Properly save and restore old cliprect v2 parentClipRect would probably be better than oldClipRect?
Attachment #506431 - Flags: review?(jmuizelaar) → review+
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Starting from today's nightly I keep seeing black a toolbox on each new tab I open, and tabs disappear... I'm on d3d9 and others on d3d10 don't seem to be able to reproduce. Please check bug 628658.
This push seems likely to have created Bug 628672.
Verified in Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.