Closed Bug 590568 Opened 14 years ago Closed 14 years ago

[D3D9] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: mozbugz, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [Input])

Attachments

(28 files, 1 obsolete file)

plugin area scrolled off content area shown as rectangle in chrome area
557.93 KB, image/png
Details
[D3D9] Another version of the plugin resized
175.46 KB, image/jpeg
Details
simple testcase
87 bytes, text/html
Details
slightly more interesting testcase
198 bytes, text/html
Details
black background testcase
131 bytes, text/html
Details
Screenshot
11.64 KB, image/png
Details
even creepier screenshot
52.29 KB, image/png
Details
Simplified XUL testcase
542 bytes, application/vnd.mozilla.xul+xml
Details
D3DTest.cpp
7.57 KB, text/plain
Details
fix
1.88 KB, patch
jimm
: review+
Details | Diff | Splinter Review
Change of bug rendering in toolbars from white rectangle to "Aero" effect in Windows 7
227.32 KB, image/png
Details
Plugin content is improperly rendered outside the toolbar area.
1008.06 KB, video/webm
Details
situation after recent d3d9 changes
33.96 KB, image/jpeg
Details
Change of bug rendering. Gecko/20101221 Firefox/4.0b9pre
428.05 KB, image/png
Details
Glitches Gecko/20101223 Firefox/4.0b9pre
175 bytes, text/html
Details
Patch 2: try resetting clip region immediately before and after moving/resizing the plugin window, if we're clipped
6.14 KB, patch
Details | Diff | Splinter Review
Patch 3: repaint under the moved plugin
4.87 KB, patch
Details | Diff | Splinter Review
Screencast with bug behaviour with tryserver-build (fc2bc1ec371c)
175 bytes, text/html
Details
"flickering" + "persistent damage" tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c
784.51 KB, video/webm
Details
Screencast "Persistent damage" Minefield Gecko/20101227 Firefox/4.0b9pre
1.33 MB, video/webm
Details
Screencast of glitches outside the toolbar area tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c
1.46 MB, video/webm
Details
screencast of plugin overwriting chrome on first scroll and flickering
1.35 MB, video/webm
Details
Screencast resizing window Gecko/20101229 Firefox/4.0b9pre
416.74 KB, video/webm
Details
patch for checkin - always update stored window clip region
3.66 KB, patch
tnikkel
: review+
Details | Diff | Splinter Review
Sample Paint Error latest patch
80.11 KB, image/jpeg
Details
Screencast overlaying of plugin area over site toolbar. Gecko/20110101 Firefox/4.0b9pre
784.60 KB, video/webm
Details
Before Scrolling
84.27 KB, image/jpeg
Details
After Scrolling
95.21 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre Firefox/4.0b4pre Build Identifier: Plugin shows white/bluish box in the chrome area when scrolling a playing plugin off screen with direct2d enabled. Reproducible: Always Steps to Reproduce: 1. Turn on D2d 2. Load Youtube flash video 3. scroll page down off so video is half cut over chrome and content area Actual Results: box is shown where plugin would be painting Expected Results: No box is shown in chrome/toolbars area This is a regression from retain layers. See screenshot.
Blocks: d2d
Component: General → Graphics
Product: Firefox → Core
Version: unspecified → Trunk
Blocks: 564991
Keywords: regression
blocking2.0: --- → beta5+
QA Contact: general → thebes
This is blocking B5+ and still marked Uncomfirmed? Setting status to New since I can confirm this behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2) > This is blocking B5+ and still marked Uncomfirmed? Setting status to New since > I can confirm this behavior. How do you reproduce it, we haven't seen it on any of our machines. I can't seem to reproduce it anywhere either? (I can reproduce the flash invalidation bug, but that doesn't interfere with chrome) What kind of hardware are you on and what drivers? Also are you manually turning on D2D or is it being turned on by default?
(In reply to comment #0) > Steps to Reproduce: > 1. Turn on D2d > 2. Load Youtube flash video > 3. scroll page down off so video is half cut over chrome and content area > Actual Results: > box is shown where plugin would be painting How consistently can you reproduce this?
I can reproduce 100%, I was trying to figure out how to make a screencast incase the STR is a bit fuzzy. Testing on Nvidia 7050 D3D9, D2D enabled using render-mode 6.
It happens as I scroll the page down/up and plugin moves under the chrome/toolbars area. the video doesn't always have to be playing, but as the plugin goes off the screen edge, it shows a rectangle about the same as the area moving off, but in the chrome area, so when I release the mouse and move it around, the rectangle in the chrome area will disappear.
(In reply to comment #5) > I can reproduce 100%, I was trying to figure out how to make a screencast > incase the STR is a bit fuzzy. Testing on Nvidia 7050 D3D9, D2D enabled using > render-mode 6. If you're on recent trunk builds, render-mode 6 is not D2D enabled.
its forced on using 6. about:support Graphics Adapter Description NVIDIA GeForce 7050 / NVIDIA nForce 610i Vendor ID 10de Device ID 07e3 Adapter RAM 256 Adapter Drivers nvd3dum 捑ဈ Driver Version 8.17.12.5721 Driver Date 6-7-2010 Direct2D Enabled true DirectWrite Enabled true
The video in question does all sorts of strange things on my system. I get an empty grey screen with the audio playing. Sometimes I'll get the video playing in this same grey screen. Sometimes just an empty white screen. In all cases I eventually get a screen with the close button (X) so I can get out of it. I have an ATI HD5870. Direct2D Enabled true DirectWrite Enabled true Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre - Build ID: 20100827101721
Updated URL with YouTube screencast of this bug.
URL: http://www.youtube.com/watch?v=VbMeEO... → http://www.youtube.com/watch?v=IejYtD...
I believe that Rob wanted to look into this.
Assignee: nobody → roc
If I turn off DirectWrite pref, but leave on the Render Mode pref at 6, I see a section of the flash object painting instead of a white rectangle box.
(In reply to comment #12) > If I turn off DirectWrite pref, but leave on the Render Mode pref at 6, I see a > section of the flash object painting instead of a white rectangle box. I see it the plugin paint in the chrome no matter what the preferences are set to after this hourly cset: http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa which changed the behavior of this bug.
Filed bug 591570 for the new behavior and didn't know if we should morph this bug.
This one shows white over gradient toolbars, and black in glass area, when using the resize plugin option
(In reply to comment #15) > Created attachment 470158 [details] > [D2D] Another version of the plugin resized > > This one shows white over gradient toolbars, and black in glass area, when > using the resize plugin option I wouldn't be surprised if after 130078 landed tonight, and once the subsequent bugfixes are landed. This bug either completely changes behavior or doesn't reproduce anymore.
This bug is still reproduceable in the nightly.
(In reply to comment #17) > This bug is still reproduceable in the nightly. Neat. Might be a D3D9 issue I suppose.
WFM, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100829 Firefox/4.0b5pre. I see some pretty nasty scroll artifacts in the plugin window, but I think that might be another bug.
Unless this can be reproduced with DX10 hardware, this doesn't block at all.
blocking2.0: beta5+ → -
ATI 5870 w/ Cat 10.8 drivers on Win 7 Pro x64 and the only thing I see are issues like http://imgur.com/N0046.png on Youtube while scrolling, sometimes switching tabs or minimizing and maximizing the windows eradicates them until I scroll again.
(In reply to comment #21) > ATI 5870 w/ Cat 10.8 drivers on Win 7 Pro x64 and the only thing I see are > issues like http://imgur.com/N0046.png on Youtube while scrolling, sometimes > switching tabs or minimizing and maximizing the windows eradicates them until I > scroll again. This is bug 587508. It's reproducable for everyone.
updating summary, the color is not real important, as it also changes based on using personas; I've seen it shown as black and gray as well.
Summary: [D2D] plugin area shown in toolbars when scrolled off the screen as a blue/white box → [D2D] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled
Should bug 585912 or this one be duped to each other?
Since D2D is on by default now, shouldn't this be blocking?
Not unless this can be reproduced with DX10 hardware. See comment 20.
I'm seeing this bug with the latest nightly on Win7x64 and Adapter Description NVIDIA GeForce 7600 GT Vendor ID 10de Device ID 0391 Adapter RAM 256 Adapter Drivers nvd3dumx,nvd3dum Driver Version 8.17.11.9713 Driver Date 3-15-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9
I've been seeing this since direct3d layers got turned on by default. My system: Windows 7 x64 (32 bit Fx and Flash) Adapter Description NVIDIA GeForce 7600 GS Vendor ID 10de Device ID 0392 Adapter RAM 256 Adapter Drivers nvd3dumx,nvd3dum Driver Version 8.17.12.5896 Driver Date 7-9-2010 Direct2D Enabled false DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9 So looks like might be an issue with either NVidia GeForce 7600 and/or Win7 x64. Also, when I try and copy/paste the table from about:support, it comes out like this: Adapter DescriptionNVIDIA GeForce 7600 GS Vendor ID10deDevice ID0392Adapter RAM256Adapter Driversnvd3dumx,nvd3dumDriver Version8.17.12.5896Driver Date7-9-2010Direct2D EnabledfalseDirectWrite EnabledtrueGPU Accelerated Windows1/1 Direct3D 9 Off-topic, I know, but very annoying...
This is being reported by people with no D2D, but just D3D9.
Summary: [D2D] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled → [D3D9] plugin area is shown in toolbars when scrolled off the screen as a rectangle about the size of plugin area being scrolled
i have same issue with Adapter DescriptionNVIDIA GeForce 7600 GS Vendor ID10de Device ID0392 Adapter RAM 512 Adapter Drivers nvd3dum Driver Version8.17.12.6063 Driver Date9-10-2010 Direct2D Enabledtrue DirectWrite Enabledtrue GPU Accelerated Windows1/1 Direct3D 10
I still have the same problem, using latest beta drivers (260.89). Adapter Description NVIDIA GeForce 7600 GT Vendor ID 10de Device ID 0391 Adapter RAM 256 Adapter Drivers nvd3dumx,nvd3dum Driver Version 8.17.12.6089 Driver Date 10-8-2010 Direct2D Enabled false DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9
ok the issue is partially fixed with the bug https://bugzilla.mozilla.org/show_bug.cgi?id=600908 (fixed in the hourly http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1286860041/ ) now the withe box over the toolbar is showed less and just during fast scrolling , when you stop to scroll the toolbar is repainted over it)
sorry , i partialli fix just some youtube , but the problem still here in the strongest way , please try www.autoblog.it (page with some embeded flash player)
I wonder if this and bug 593703 are the same?
(In reply to comment #34) > I wonder if this and bug 593703 are the same? It looks like it to me, the screenshot is what I think makes it so, even though I didn't read all the way through that bug.
yes it is the same, could we move to the other bug ?
Time to mark this bug as dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=593703 ?
Other way around.
i know , title already said it , but just to confirm , that even using DX9 card , enabling "layers.use-d3d10" the youtube glitch disappears , so we can assume that the issue is on layer code and not on flash
another round strange situation here: layers.accelerate-all;false layers.prefer-d3d9;false gfx.direct2d.force-enabled;true result in Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Windows 0/1 all seams accelerated , i have better score on ie9 test drive than before all the glitch (black box , trasparent layer not rendere etc etc) gone flash player glitch gone (a white box is drawed on the toolbar but is repainted almost immediatly with chrome element)
(In reply to comment #40) > layers.prefer-d3d9;false > GPU Accelerated Windows 0/1 Bas, I'm guess it should be a d3d10 as a GPU accelerated Window, not 0/1, no? This bug is still about d3d9 regardless.
(In reply to comment #41) > (In reply to comment #40) > > > layers.prefer-d3d9;false > > GPU Accelerated Windows 0/1 > > Bas, I'm guess it should be a d3d10 as a GPU accelerated Window, not 0/1, no? > I see the issue with that now.. read on: (In reply to comment #40) > layers.accelerate-all;false > layers.prefer-d3d9;false > gfx.direct2d.force-enabled;true I see you have layer.accelerate-all;false. about:support would of said GPU Acceleration: Direct3D 10 1/1, so your just running D2D/DW, not D3D9 or D3D10, so false alarm. We already know this case works.
if im using accelerate-all; true, i have the D3D10 work well with flash player but if i force to use D3D9 the flash player paint over the crhome toolbar
The white rectangle don't occur when scrolling on Liveleak.com video site (different video flash player?): http://www.liveleak.com/view?i=84c_1288188804 but I have 100% repetition of this bug on any Youtube video. More info: Windows 7 32bit Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre Adapter Description ATI MOBILITY RADEON X1300 Vendor ID 1002 Device ID714a Adapter RAM 128MB Drivers atiumdag atiumdva atitmmxx Driver Version 8.593.100.0 Driver Date 2-10-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9
I have the same problem. Windows7 32bit Mozilla/5.0 (Windows NT 6.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Adapter Description ATI RADEON X1600 Driver Version 8.56.1.15
That's odd, I thought this would've been fixed by all the work we've done on plugins.
Wow, this is certainly not fixed. I'm currently using FlashBlock to make the browser usable with hardware acceleration on. (The browser is _so_ much faster with acceleration that I'd rather give up convenient Flash.) Personally, I hadn't followed up because I assumed it was being worked on. Did you need regular reports on whether this has been fixed yet?
Hrm, well, mainly I wish I had a clue about what's going on. I can't reproduce it anywhere either.
Reproducible here: http://www.bbc.co.uk/news/uk-politics-11728546 Play the vid and scroll up. (b8 pre Win32 20101111)
So there must be some code in D3D9 that is different then the D3D10 path here, no?
Comment 50's video link works fine for me just fine with D3D10.
Ok...now I'm going to show my ignorance (I'm just semi-technical trying to help). What is D3D9 / D3D10...?
(In reply to comment #53) > Ok...now I'm going to show my ignorance (I'm just semi-technical trying to > help). What is D3D9 / D3D10...? If it's DirectX - I'm running 11 (Win7)
(In reply to comment #54) > (In reply to comment #53) > > Ok...now I'm going to show my ignorance (I'm just semi-technical trying to > > help). What is D3D9 / D3D10...? > > If it's DirectX - I'm running 11 (Win7) It is part of DirectX - if you're running DirectX 11, then your Firefox should be using Direct3D 10 (D3D10). Typing "about:support" into your address bar should tell you.
(In reply to comment #55) > (In reply to comment #54) > > (In reply to comment #53) > > > Ok...now I'm going to show my ignorance (I'm just semi-technical trying to > > > help). What is D3D9 / D3D10...? > > > > If it's DirectX - I'm running 11 (Win7) > > It is part of DirectX - if you're running DirectX 11, then your Firefox should > be using Direct3D 10 (D3D10). Typing "about:support" into your address bar > should tell you. OK...strange...In dxdiag it says I'm using DirectX 11. In about:support it tells me Direct3D 9! Maybe I should download DirectX and re-install + test..?
Do you have a Dx10 capable graphics card? Are you sure that you don't force D3D9 in about:config?
(In reply to comment #57) > Do you have a Dx10 capable graphics card? I don't know - it's a fairly humble NVidia GeForce 6600 > Are you sure that you don't force D3D9 in about:config? Not that I have knowingly changed - which setting in about:config?
Doesn't matter, 6600 is not a Dx10 capable card, that's why you use D3D9.
I'm glad your all willing to help, but this bug is not about debugging your PC's version of support for DirectX or Firefox's D3D level of support to see if you see this bug, that belongs in support forums. Next time, can you please take that elsewhere as Bugzilla is not a forum for discussion? We know Firefox only supports various configurations of rendering, D3D9 is one of them, and the Nvidia 6600 is about the same as the 7xxx series so that makes sense you will see this bug as it is a D3D9 part. The pieces that we noticed trigger this bug are: hardware acceleration turned on in Advanced options layers.prefer-D3D9;true layers.accelerate-none;false layers.accelerate-all;true and some flavors of Nvidia and ATI cards or onboard video devices. If this bug is reproducible under other configurations, then we want to know about it.
(In reply to comment #60) > I'm glad your all willing to help, but this bug is not about debugging your > PC's version of support for DirectX or Firefox's D3D level of support to see if > you see this bug, that belongs in support forums. Next time, can you please > take that elsewhere as Bugzilla is not a forum for discussion? > > We know Firefox only supports various configurations of rendering, D3D9 is one > of them, and the Nvidia 6600 is about the same as the 7xxx series so that makes > sense you will see this bug as it is a D3D9 part. > > The pieces that we noticed trigger this bug are: > > hardware acceleration turned on in Advanced options > layers.prefer-D3D9;true > layers.accelerate-none;false > layers.accelerate-all;true > and some flavors of Nvidia and ATI cards or onboard video devices. > > If this bug is reproducible under other configurations, then we want to know > about it. I appreciate all of that, and I only posted here as I could reproduce the bug which Bas said he couldn't, which then led down this road. Infuriating as b6 did not show this problem. b7 onwards does...
I can still reproduce this with the video in comment #50 and most other flash videos on the web. Adapter Description NVIDIA GeForce 7950 GT Vendor ID 10de Device ID 0295 Adapter RAM 256 Adapter Drivers nvd3dumx,nvd3dum Driver Version 8.17.12.6099 Driver Date 10-16-2010 Direct2D Enabled false DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9 When I had an ATI R5870 in this machine, I was not seeing this issue at all.
I can reproduce this bug in my VMWare Win7 VM. I'm planning to try to analyze it using record-and-replay, but I had trouble getting record-and-replay debugging going on my laptop and I've been busy with other stuff since. I will get back to this.
(In reply to comment #63) > I can reproduce this bug in my VMWare Win7 VM. I'm planning to try to analyze > it using record-and-replay, but I had trouble getting record-and-replay > debugging going on my laptop and I've been busy with other stuff since. I will > get back to this. Hrm, never occurred to me to try this in a Win7 VM, interesting idea, I wonder if it will repro there for me too.
I believe both of these are dupes of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=597955 https://bugzilla.mozilla.org/show_bug.cgi?id=593703 @Baz, comment #65 : Roc managed to reproduce the issue in a VM, assuming the above two bugs are indeed dupes of this one. For the relevant comment, see: https://bugzilla.mozilla.org/show_bug.cgi?id=593703#c48 Again, assuming the two bugs above are dupes, see here for the reduced test case: https://bugzilla.mozilla.org/show_bug.cgi?id=593703#c46
I think the following bug is the same as the following one: https://bugzilla.mozilla.org/show_bug.cgi?id=608533
(In reply to comment #68) > I think the following bug is the same as the following one: > > https://bugzilla.mozilla.org/show_bug.cgi?id=608533 Apologies for the nonsensical sentence. I can confirm this too. --- Sony VAIO VGN-AR41E Windows 7 NVidia Geforce 8400M GT (Driver v167.60) ---
with the build 20101113 is fixed for me, the rectangle is painted for just a frame and even for fast scrolling , but it is repainted with the toolbar almost immediatly. Tested here www.autoblog.it www.cineblog.it layer accelerate all true d2d enabled and layers.prefer-d3d9 true
Not fixed for me using: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101113 Firefox/4.0b8pre Adapter Description: NVIDIA GeForce 6200 TurboCache(TM) Vendor ID: 10de Device ID: 0161 Adapter RAM: 64 Adapter Drivers: nvd3dumx,nvd3dum Driver Version: 8.17.12.5896 Driver Date: 7-9-2010 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated Windows: 1/1 Direct3D 9
Sorry , was my fault , i was posting from the computer with a dx10 card , it still NOT FIXED
Attachment #470158 - Attachment description: [D2D] Another version of the plugin resized → [D3D9] Another version of the plugin resized
(In reply to comment #44) > duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=593839 ? Thats a different bug.
Still showing here at BBC News as before. 20101114. D3D9.
BTW does everyone see this with with OOPP enabled *and* disabled? I'm guessing this is a driver bug where the driver incorrectly ignores the WindowRgn of the plugin window. I need to check by writing a D3D test app. If so, then for OOPP we can probably work around this fairly easily by altering the size and position of the plugin HWND to be the bounds of the window clip region. That'll be harder for non-OOPP though.
In my experiments this only happens when "Use hardware acceleration when available" is checked. If you disable this option then objects scroll as expected.
(In reply to comment #77) > BTW does everyone see this with with OOPP enabled *and* disabled? It does for me. (In reply to comment #78) > In my experiments this only happens when "Use hardware > acceleration when available" is checked. Probably because you have a D3D9 card. > If you disable this option then objects scroll as expected. This is expected and confirmed already, since this is a D3D9 bug, and D3D9/10 would not show as accelerated windows (in about:support) when you turn off this option because it flips the prefs to this: layers.accelerate-none;true layers.accelerate-all;false
(In reply to comment #77) > BTW does everyone see this with with OOPP enabled *and* disabled? Yes, it happens with OOPP disabled too (dom.ipc.plugins.enabled;false).
Some use cases can be found here on the following Input query: http://input.stage.mozilla.com/en-US/search/?q=white+&product=firefox&version=4.0b7&date_start=&date_end=&os=win7
Whiteboard: [Input]
(In reply to comment #77) > BTW does everyone see this with with OOPP enabled *and* disabled? > > I'm guessing this is a driver bug where the driver incorrectly ignores the > WindowRgn of the plugin window. I need to check by writing a D3D test app. If > so, then for OOPP we can probably work around this fairly easily by altering > the size and position of the plugin HWND to be the bounds of the window clip > region. That'll be harder for non-OOPP though. Hi, excuse the possibly naive question, but why did this problem only show itself post b6? What changed?
(In reply to comment #82) > (In reply to comment #77) > > BTW does everyone see this with with OOPP enabled *and* disabled? > > > > I'm guessing this is a driver bug where the driver incorrectly ignores the > > WindowRgn of the plugin window. I need to check by writing a D3D test app. If > > so, then for OOPP we can probably work around this fairly easily by altering > > the size and position of the plugin HWND to be the bounds of the window clip > > region. That'll be harder for non-OOPP though. > > Hi, excuse the possibly naive question, but why did this problem only show > itself post b6? What changed? We enabled accelerated layers as of b7pre. So the problem would not exist in b6.
Should this block beta?
I think this has to block. I don't know about Joe's comment about DX10 hardware, but it shows up for a lot of people.
blocking2.0: - → ?
Hello, a few comments here appear claim that the problem is with cards that only support DX9 (at least that's what I got from them ;-)) I'm confused now... My dxdiag.exe says DirectX 10. My graphics card is an NVidia GeForce 8400m GT, which claims to support DX10: - "The NVIDIA GeForce 8400M also enables you to play the hottest new games featuring DirectX 10." (http://www.nvidia.com/object/geforce_8M.html) - "NVidia GeForce 8400M GT is the DirectX 10 capable successor of the GeForce Go 7400 for laptops" (http://www.notebookcheck.net/NVidia-GeForce-8400M-GT.3708.0.html) I'm not trying to prove anyone wrong. I probably just misunderstood, however, my card *seems* to be DirectX 10 capable, but I still have the problem (and Firefox reports that its using d3d9). It's probably not important, but I though it wise to point it out.
Regarding comment 20, this was originally a problem with D2D, and we don't support D2D on D3D9 hardware. However, if people are seeing this using only D3D9 layer compositing, we need to block on this.
blocking2.0: ? → betaN+
(In reply to comment #88) > Hello, a few comments here appear claim that the problem is with cards that > only support DX9 (at least that's what I got from them ;-)) > > I'm confused now... > > My dxdiag.exe says DirectX 10. > My graphics card is an NVidia GeForce 8400m GT, which claims to support DX10: > - "The NVIDIA GeForce 8400M also enables you to play the hottest new games > featuring DirectX 10." (http://www.nvidia.com/object/geforce_8M.html) > - "NVidia GeForce 8400M GT is the DirectX 10 capable successor of the GeForce > Go 7400 for laptops" > (http://www.notebookcheck.net/NVidia-GeForce-8400M-GT.3708.0.html) > > I'm not trying to prove anyone wrong. I probably just misunderstood, however, > my card *seems* to be DirectX 10 capable, but I still have the problem (and > Firefox reports that its using d3d9). > > It's probably not important, but I though it wise to point it out. Support for DX10 tends varies by card, and manufacturers are always updating drivers. Again, we're not really comparing DX10 dxdiag software install support in Windows here against Firefox's support level, but we're checking Firefox's rendering code path like D3D9. I would also encourage anyone to also take a look at bug 612186 as Bas had some good info to share there.
Attached file simple testcase —
I see this in VMWare with D3D9 enabled and D2D disabled. This is about the simplest possible testcase and it reproduces 100%.
This testcase shows that the problem (in VMWare at least) is specifically triggered by the nsIWidget->Move() call in ConfigureChildren. Load it -> no problem, then click in the page -> problem.
Load this one and then make the window narrow so that the right window edge overlays the plugin. On my setup, I see some kind of weird highlight effect in the rightmost two columns of pixels in the plugin.
Attached image Screenshot —
This shows the highlight effect. Note how it doesn't happen above the top edge of the plugin window.
If I make the window vertically small, I get an even creepier screenshot. The plugin makes the whole browser window partially transparent --- or something --- where the plugin window is. These last two problems I can reproduce on my Nvidia card outside the VM, actually. But only with D3D9.
Er, wrong. Actually I see those two problems with no acceleration at all! And with D3D9, and with D3D10 (+D2D).
I'll treat those as unrelated and spin off a new bug for them.
(In reply to comment #93) > Created attachment 491439 [details] > black background testcase What plugin is this supposed to be using? I apparently don't have it, and the plugin finder service isn't finding anything either.
The test plugin. You need a build which was built with tests enabled, I'm not sure where you would download one.
(In reply to comment #96) > Er, wrong. Actually I see those two problems with no acceleration at all! And > with D3D9, and with D3D10 (+D2D). They happen with OOPP disabled too.
This bug also seems to be independent of OOPP. In my VM, it seems to happen with D3D10 too, although the symptoms are a little different, I only get the white overlay while I'm dragging the scroll button. Although VMWare is pretty broken with D2D so who knows.
Actually I'll keep analyzing all these bugs here since I think these bugs are likely to be closely related.
You'll need to whitelist XUL in Bugzilla (or download the testcase and whitelist file:///) to view this testcase. This gives us a pretty good indication of what's going on. It looks like the DWM does not get along with child windows where we ask it to extend glass margins into the client area.
Attached file D3DTest.cpp —
Here's a standalone D3D9 test app. It shows pretty clearly that when you use DwmExtendFrameIntoClientArea to extend glass into the client area, child windows over those margins do not get composited correctly by the DWM. Even if we draw opaque content over the margins. Clicking in the app window moves the child window. Interestingly, it does NOT reproduce this bug as originally reported.
(In reply to comment #104) > Created attachment 491769 [details] > D3DTest.cpp > > Here's a standalone D3D9 test app. Interestingly, it does NOT > reproduce this bug as originally reported. I know it seemed to changed since I first spotted this. (In reply to comment #89) > Regarding comment 20, this was originally a problem with D2D, and we don't > support D2D on D3D9 hardware. However, if people are seeing this using only > D3D9 layer compositing, we need to block on this. Yup, that's correct as far as I could tell in early comments. Before I had forced D2D/DW on and used D3D9 in comment 8, and looked like it was changed by another bug, then Bas said it didn't matter to use D2D by comment 29, and then confirmed it with D3D9 only without D2D, so I updated the bug info. (In reply to comment #20) > Unless this can be reproduced with DX10 hardware, this doesn't block at all. Given the bad support of my Nvidia 7050 device :), I can now also reproduce this bug using Direct3D 10 acceleration given the following: 1) Updated to latest drivers since comment 8. 2) about:config prefs: gfx.direct2d.force-enabled;true gfx.font_rendering.directwrite.enabled;true layers.prefer-d3d9;false layers.accelerate-none;false layers.accelerate-all;true as shown here, its trying to use Direct3D 10: Adapter Description NVIDIA GeForce 7050 / NVIDIA nForce 610i Vendor ID 10de Device ID 07e3 Adapter RAM 256 Adapter Drivers nvd3dum Driver Version 8.17.12.6099 Driver Date 10-16-2010 Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 10
I changed my mind again and filed bug 613449 on the problems of drawing windowed plugins over the DWM glass margins.
Depends on: 613449
I verified via debugging that the white rectangle appears the instant we call SetWindowPos from nsWindow::Move from nsWindow::ConfigureChildren.
If I pass SWP_NOCOPYBITS to SetWindowPos, the problem does not occur. So as far as I can tell, there is some kind of driver/platform bug with SetWindowPos moving a child window that has a clip region set on it with SetWindowRgn, that as far as we know only manifests when the parent window is using D3D9. The SetWindowPos call tries to copy the bits of the child window from the old to the new location, but incorrectly paints white outside the clip region in the new location. So I think a reasonable workaround is to pass SWP_NOCOPYBITS to SetWindowPos when we're using D3D9 and the child's clip region is not covering its entire window.
(It seems that with SWP_NOCOPYBITS, instead of copying bits, SetWindowPos invalidates the affected areas, so normal repainting will redraw everything.)
Attached patch fix — — Splinter Review
Seems to work. I can't think of any better workaround at this point. There will be a slight performance hit when scrolling when plugins are partially visible.
Attachment #492542 - Flags: review?(jmathies)
Whiteboard: [Input] → [Input][needs review]
Hmm, we want this for D3D9 only right, so shouldn't that be: (mLayerManager && mLayerManager->GetBackendType() == LayerManager::LAYERS_D3D9)
If there's somehow no layer manager yet, I'm being conservative and just doing the SWP_NOCOPYBITS. I doubt that will actually happen in practice.
Comment on attachment 492542 [details] [diff] [review] fix (In reply to comment #112) > If there's somehow no layer manager yet, I'm being conservative and just doing > the SWP_NOCOPYBITS. I doubt that will actually happen in practice.
Attachment #492542 - Flags: review?(jmathies) → review+
Whiteboard: [Input][needs review] → [Input][needs landing]
Comment on attachment 492542 [details] [diff] [review] fix Pushed this as http://hg.mozilla.org/mozilla-central/rev/a49bc63fe3d0 I didn't notice until afterwards, but the bug number mentioned in the patch is not this one.
Whiteboard: [Input][needs landing] → [Input]
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Is the fix supposed to be in the latest nightly? If so, I can still reproduce the problem. See details in duplicate bug report: Bug 599695
I can also replicate using latest nightly: - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre ID:20101207030325 - Flash: 10.1.102.64
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I cannot reproduce with the testcases in this bug, but I can reproduce easily scrolling the video at the end of this page http://www.engadget.com/2010/12/07/google-nexus-s-preview/
Blocks: d3d9-layers
In past nigtly builds the plugin area in toolbars are usually a white rectangle. From few nigtly build the plugin area in toolbars looks like "aero" effect in windows 7. Look into attachement for more info. Windows 7 32bit Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre Adapter Description ATI MOBILITY RADEON X1300 Vendor ID 1002 Device ID714a Adapter RAM 128MB Drivers atiumdag atiumdva atitmmxx Driver Version 8.593.100.0 Driver Date 2-10-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9
(In reply to comment #121) > Created attachment 497282 [details] > Change of bug rendering in toolbars from white rectangle to "Aero" effect in > Windows 7 > > In past nigtly builds the plugin area in toolbars are usually a white > rectangle. From few nigtly build the plugin area in toolbars looks like "aero" > effect in windows 7. Look into attachement for more info. The same thing with me: I also see the Aero effect instead of the white rectangle on most websites. However, using the previously mentioned video, I still see a white rectangle as was the initial problem. http://www.engadget.com/2010/12/07/google-nexus-s-preview/ (The video is at the bottom of the post.)
(In reply to comment #120) > I cannot reproduce with the testcases in this bug, but I can reproduce easily > scrolling the video at the end of this page > http://www.engadget.com/2010/12/07/google-nexus-s-preview/ Here is some problem. Even on other sites which have some form of player (youtube etc). Also here > http://www.bbc.co.uk/news/uk-11989216 Small player is on middle of page and when you scroll up page it leaves white rectangle on firefox gui and also when you scroll down. OS Windows 7 x64 Default FF skin, doesn't matter if personas are place or not. User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Graphics Adapter Description NVIDIA GeForce 7900 GT/GTO Vendor ID 10de Device ID 0291 Adapter RAM 512 Adapter Drivers nvd3dumx,nvd3dum Driver Version 8.17.12.6099 Driver Date 10-16-2010 Direct2D Enabled false DirectWrite Enabled false GPU Accelerated Windows 1/1 Direct3D 9
Plugin content is also improperly rendered outside the toolbar area. Please check attached video (webm) file for more information.
Interesting, I cannot reproduce anymore after latest D3D9 changes from yesterday...
Well, not completely true... something changed but not all. Now it does not clear anymore the toolbars area, but I still see it clearing the locationbar contents and the tabbar gets messed up (content moves to the right)
This is what I see... the tabbar is duplicating content that is on the left, the locationbar is white on the plugin area... but now toolbars are correct. moving mouse over it fixes the glitches.
In addition to comment 128. I can also see the shift of the content from the left side of browser. But toolbars are affected by glitches. Check the attached screenshot for more info (pay attention that in title bar, menu button appear twice).
I'm still seeing this bug the way I reported it, happens a little less often with Normal window mode, and more often in Maximized mode for me. I don't see any issues from the past few comments, they look different. (In reply to comment #124) > Created attachment 497654 [details] > Plugin content is improperly rendered outside the toolbar area. > > Plugin content is also improperly rendered outside the toolbar area. Please > check attached video (webm) file for more information. hmm, this looks like a webpage trying to create a toolbar on the website (not part of Firefox chrome) but doing similar things, I think this bug might be better spun off, unless Roc disagrees. (In reply to comment #129) > Created attachment 499119 [details] > Change of bug rendering. Gecko/20101221 Firefox/4.0b9pre > > In addition to comment 128. I can also see the shift of the content from the > left side of browser. But toolbars are affected by glitches. > Check the attached screenshot for more info (pay attention that in title bar, > menu button appear twice). I don't see this mess at all.
(In reply to comment #128) > Created attachment 499054 [details] > situation after recent d3d9 changes > > This is what I see... the tabbar is duplicating content that is on the left, > the locationbar is white on the plugin area... but now toolbars are correct. > moving mouse over it fixes the glitches. I don't see the duplicate tabbar mess, but I noticed the rest can happen sometimes, but it doesn't happen consistently using the Fx menu with a persona.
I am using Windows 7 with "Aero-Design". With "Aero-Design" I can also see the white rectangle in FF's toolbar when scrolling. But when I switch to e. g. "Windows 7 BASIS Design" (which means Aero is turned off) the here described bug does not occur any more. Maybe this informaiton helps for fixing the bug .
Gecko/20101223 Firefox/4.0b9pre Check the repeatable bug rendering behaviour on attached screencast: http://www.youtube.com/watch?v=Vi247LAANLY >Maximized browser window (after tab closing, nonclickable 'ghost' tab appear, link in address bar is messed) >Unmaximized browser window (shifting of toolbar content in plugin area) >After using system button 'show desktop' and restoring browser window, plugin area is rendered as glass Aero effect. But sometimes the plugin area render as: -white rectangle -sometimes the only visible glitch is on the bookmark bar, when favicons are missing but text stay in proper position.
I thought this workaround might fix the problem, but it's no good, it causes the plugin to flicker in the chrome area sometimes.
This patch might be a decent workaround. It just repaints the area under the plugin when we move a clipped plugin. For people that are seeing this bug, they might still see a flicker of white in the chrome area with this patch, but that's all. I can't reproduce the problem, so people are going to have to try tryserver builds. A build with this patch will appear at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c. If this solution doesn't work or isn't acceptable, the only other approach I can think of right now would be to inject a parent window for the plugin window and use that parent window to clip the plugin window to a rectangle. I don't know if that would avoid these driver bugs or not.
(and even if it works, it would be a bit risky)
(In reply to comment #135) > I can't reproduce the problem, so people are going to have to try tryserver > builds. A build with this patch will appear at > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-fc2bc1ec371c. Well, it flickers more with this patch, that's about the only thing I see is different, but its definitely there :(
By "flickering" I mean something that draws incorrectly but only for a moment, and is then replaced by the correct content. When I reproduce this bug in my VM, I see stuff drawing incorrectly and it is not replaced by the correct content until something causes the window to redraw, e.g. by moving the mouse over stuff. Let's call that "persistent damage". So on trunk, are you seeing flickering or persistent damage? How about with the latest patch?
The bug rendering behaviour in latest nigtly trunk or tryserver build is still present as described in comment 133. Except that in tryserver build, plugin area is repainted with very annoying flickering. Check screencast for more info: http://www.youtube.com/watch?v=kje7lK01Vlk
Can you answer the questions in comment #138? I can't really tell from your screencast.
As for reply in comment 138. In tryserver build I can see both of behaviours called "flickering" + "persistent damage", please check the attachement.
In nigtly trunk I can see only "persistent damage" behaviour. The rendering of bug is the same as described in comment 133.
In addition to comment 124 Rendering of plugin glitches still occur outside the toolbar area with tryserver (fc2bc1ec371c) or nigtly (Gecko/20101227 Firefox/4.0b9pre) build. Link to site with frame/toolbar: http://bit.ly/bzcGpO
This bug is about glitches appearing in the browser chrome. You don't seem to be seeing that, so your bug is quite likely to be something else.
It is a fair bit better with the tryserver build, but not perfect. By that I mean that maybe 4 in every 5 "scroll plugin into chrome" cases repaint properly (albeit with flickering), but 1 in 5 don't.* That is, 1 in 5 times chrome messes up and stays messed up until either mouse over or another scroll event. Also, the latter (scrolling causing a proper repaint) is new behaviour because that never happened before. So this looks close to what's needed. * These numbers aren't exact. :)
OK, that's helpful, thanks! Is the 1 in 5 that don't cause proper repaint any obvious special case? E.g., is it always when a plugin changes from "fully visible" to "partially visible"? Or when it changes from "completely invisible" to "partially visible"? Supposing we fix that 1 in 5 case, how bad is the flickering?
Yes, it only happens the first time the plugin needs to be clipped (i.e. "fully visible" to "partially visible"). It didn't seem that way yesterday, but perhaps I wasn't paying close enough attention then. The flickering is annoying, certainly, but I think liveable given it doesn't occur everywhere. Each scroll event does not result in the same delay before repaint, so sometimes the flicker is very noticeable and other times it's barely noticeable. Maybe the repaint timing could be refined somehow to minimise the delay before scroll event triggers a repaint? Anyway, I'll attach a screencast.
The first part of the screencast shows the plugin area overwriting chrome persistently the first time the plugin needs clipping, but being repainted on subsequent scroll events. (Also, I first scroll with the mouse wheel, then the keyboard.) The last part of the screencast shows the severity of the flickering, particularly noticeable when scrolling quickly.
I find this difficult to describe without a screencast also, so I was going to produce one. I see the flickering on fc2bc1ec371c, but it refreshes the toolbars quickly, its not always there and its noticeable as noted already. You get the feeling the plugin doesn't clip inside the content area coordinates right away. It doesn't happen as noted on non Aero Glass (comment 132) Some more weirdness I noticed. Even if you grab the window border and resize with fc2bc1ec371c, its painting the plugin over top of the content area and outside right and bottom edge beyond the scrollbars and addon bar into the glass area. Like the plugin is painting to the size of the window border as soon as you move the mouse to resize, but the rest of screen (content area, scrollbars, toolbars) does not until you stop moving. I see large black boxes as well being painted for areas around the plugin, but not in the toolbar area, then the content area is painted when you stop resizing the window and looks normal again which is fine for playback but the it make resizing quite ugly.
(In reply to comment #147) Since re-painting isn't carried out only the first time clipping occurs to an object, could it be that the 'fully visible' status of the object is only updated _after_ the decision about re-painting being required was taken? At least this would explain the described and documented behaviour.
(In reply to comment #149) > > I see large black boxes as well being painted for areas around the plugin, but > not in the toolbar area, then the content area is painted when you stop > resizing the window and looks normal again which is fine for playback but the > it make resizing quite ugly. > Is that kind of behaviour showed on attached screencast?
I'm pretty sure this will have no effect, but could people try this try server build to see if there is any difference? http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bb109b9e0665/try-w32/firefox-4.0b9pre.en-US.win32.zip
Tim, that trybuild seems to be working well for me, I don't see the white rectangle at all with that one.
That makes sense. The question, then, is whether that build represents a shippable fix for this bug, or whether we should try to fix the flickering as well.
I also don't see the glass rectangle either with that build. I think I could not quite tell if that build introduced other things besides making the rectangle disappear or not like more slowness in smooth scrolling/UI responsiveness issues, choppier plugin playback or if plugin flickering was present. I'm leaning toward the possibility of a slight perf hit in that build after comparing it to the trunk a few times. (In reply to comment #151) > Created attachment 500333 [details] > Is that kind of behaviour showed on attached screencast? Not sure. It appears to be showing up on the trunk builds as well aside from the bug at hand and I was thinking about filing a separate bug for it.
(In reply to comment #152) > I'm pretty sure this will have no effect, but could people try this try server > build to see if there is any difference? > http://stage.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-bb109b9e0665/try-w32/firefox-4.0b9pre.en-US.win32.zip With that build I can't reproduce any kind of glitches (as showed in any of attached screencast) in toolbar area. Glitches outside the toolbar area are also fixed (attachment 500027 [details]). The only remaining issue is showed in attachment 500333 [details] but I think It should move to new bug (as stated in comment 155).
I'm not really sure why this fixes it, but Dennis and kolubinowicki said that it fixes it for them. You're welcome to debug it to see why. :) This originally comes from bug 616884 where we decided to not take the extra code complexity since it seemed like there was no way it could cause a problem.
Attachment #500483 - Flags: review?(roc)
+ for (PRUint32 i = 0; i < aRects.Length(); ++i) { + region.And(region, aRects[i]); this should be Or. The reason this patch helps with this bug is that the call to HasClipRegion in my patch is performed after SetWindowClipRegion(aIntersectWithExisting=PR_TRUE) and before SetWindowClipRegion(aIntersectWithExisting=PR_FALSE). So without your patch, HasClipRegion is only looking at the clip region before the plugin is moved. So if the plugin starts off unclipped and becomes clipped, the extra invalidation will not be performed, even though it should be.
Comment on attachment 500483 [details] [diff] [review] patch 4: always update stored window clip region With Or instead of And.
Attachment #500483 - Flags: review?(roc) → review+
(In reply to comment #158) > this should be Or. Good catch on the Or. > The reason this patch helps with this bug is that the call to HasClipRegion in > my patch is performed after SetWindowClipRegion(aIntersectWithExisting=PR_TRUE) > and before SetWindowClipRegion(aIntersectWithExisting=PR_FALSE). So without > your patch, HasClipRegion is only looking at the clip region before the plugin > is moved. So if the plugin starts off unclipped and becomes clipped, the extra > invalidation will not be performed, even though it should be. But the try server build I made only has my patch in it, not any of your patches (unless they landed on m-c), there is no HasClipRegion on m-c (yet?).
Ah. In that case, I have no idea!
Is it possible that we paint synchronously inside ConfigureChildren? Maybe during SetWindowPos? surely not!
But let's take your patch and then see where we are. It definitely can't hurt.
The trybuild in comment #152 fixes the rendering issue with XStandard plug-in reported in comment #118.
OK, let's get this in! I would love to know why this fixes the problem but without a machine where we can reproduce it, it's going to be difficult to find out.
This has passed try server without the And -> Or fix, but if it passes with patently wrong code, the correct code should be good!
Attachment #500545 - Flags: review+
Attachment #500483 - Attachment is obsolete: true
I was going to land this, but apparently Canada is playing a hockey game today, so I can't.
Keywords: checkin-needed
Whiteboard: [Input] → [Input][needs landing]
Changed my mind.
Keywords: checkin-needed
Whiteboard: [Input][needs landing] → [Input]
http://hg.mozilla.org/mozilla-central/rev/39db16b78175 Do we want to leave this open or resolve it fixed?
Well I'm pretty sure there is a performance hit with it especially during scrolling so scrolling feels choppier. The other thing I noticed is resizing makes the plugin shift alot. For example, resize the right border to the right, the plugin moves further to the right and back left in a bouncing motion.
It seems scrolling up and down also causing the inverse bouncing of the plugin too. I'm not sure how I got that paint error in the previous comment, but it landed on that after I taxed scrolling and resizing.
Er, that bouncing effect seems to also be on the trunk before the patch. So I guess its just scrolling performance that is the remaining side effect.
With today Minefield (Gecko/20110101 Firefox/4.0b9pre) which have (?) patches from attachment 500545 [details] [diff] [review]. I can reproduce overlaying of plugin area over site toolbar. Please check attached screencast. Could anyone check, if these kind of behavior apply just to computer configuration affected with bug 590568? Link to site http://bit.ly/f34Ejj
(In reply to comment #173) > Created attachment 500601 [details] > Screencast overlaying of plugin area over site toolbar. Gecko/20110101 > Firefox/4.0b9pre > > With today Minefield (Gecko/20110101 Firefox/4.0b9pre) which have (?) patches > from attachment 500545 [details] [diff] [review]. > > I can reproduce overlaying of plugin area over site toolbar. Please check > attached screencast. > > Could anyone check, if these kind of behavior apply just to computer > configuration affected with bug 590568? > > > Link to site > http://bit.ly/f34Ejj The above problem is not related to this bug. I filed a Bug 622417 .
If this bug is now fixed and scrolling performance is the only remaining issue, I propose we file a new bug for that.
Looks fixed here (my config is in comment #62).
(In reply to comment #175) > If this bug is now fixed and scrolling performance is the only remaining issue, > I propose we file a new bug for that. I filed bug 622492 for that.
wfm in current nightly and I was able to reproduce easily before
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Marco: oh really? You're the only developer I know of who could reproduce this! Can you help us understand why Timothy's patch fixed this? Basically, we need a stack trace for any call to nsWindow::GetWindowClipRegion between w->SetWindowClipRegion(configuration.mClipRegion, PR_TRUE) and w->SetWindowClipRegion(configuration.mClipRegion, PR_FALSE) in nsWindow::nsWindow::ConfigureChildren. That should be pretty easy to get by adding a global variable to track whether you're between those calls, and then setting a conditional breakpoint on that variable. Can you do that?
Depends on: 622492
I could also reliably reproduce this and it looks fixed for me now.
Yeah, just chiming in given roc's comment. I'll try the debugging thing today.
hm, unless I've done something wrong, with or without the patch it doesn't break for me between those 2 calls (excluded). Should I try including one of the two setWindowClipRegion calls? I can do any further debugging with or without the patch if you need it.
Hmm, the first patch in this bug probably had no effect the first time a plugin gets clipped to something other than its full rect (ie the first time it is scrolled partially out of view) because the window Move call happens between the two SetWindowClipRegion calls and so the mClipRects won't be up to date yet.
Ah, the first patch was affected! Right. Great. That explains the slowdown too: NOCOPYBITS makes us repaint the plugin when it moves.
But my patch would only change the behaviour of your patch the very first time it got partially clipped out, right? So my patch could only produce a slow down on that single paint.
Here's a new phenomenon with the latest build (2011-01-04): When plugin area is scrolled over FF's tab bar, I can see a white line on FF's tab bar. But only happens in a dinstinct position of the video - I guess it's the video's tool bar (play, pause etc.) that's somehow "overpainting" FF's tab bar. --> See screenshots.
Attached image Before Scrolling —
Attached image After Scrolling —
That looks like bug 622733. Please retry on the next nightly build.
Re comment #191: Tried with the nightly build from 2011-01-06. White line still occurs.
Bug 623463 covers the white line still happening.
Anymore idea on the analysis of the patch?
(In reply to comment #196) > Anymore idea on the analysis of the patch? It's alright at the new firefox beta. At least in my PC. Thanks!
Bug 622328 improves on the haze problem a bit. I'll probably file a follow up for any remaining issues. Although it doesn't look like we'll be able to fix it 100% of the time.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: