Last Comment Bug 672885 - Resizing a fully rendered D3D9/10 accelerated window causes flicker / failure to present back buffer
: Resizing a fully rendered D3D9/10 accelerated window causes flicker / failure...
Status: NEW
[read comment 38][Australis:M-]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 20 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 731159
Blocks: 590945 783985
  Show dependency treegraph
 
Reported: 2011-07-20 11:44 PDT by Jim Mathies [:jimm]
Modified: 2015-02-04 17:54 PST (History)
45 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test app (39.84 KB, application/zip)
2011-07-20 11:44 PDT, Jim Mathies [:jimm]
no flags Details
test app (25.04 KB, application/zip)
2011-07-20 13:21 PDT, Jim Mathies [:jimm]
no flags Details
sizing patch v.1 (7.87 KB, patch)
2011-08-11 13:38 PDT, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review
sizing patch v.2 (8.60 KB, patch)
2011-08-12 03:24 PDT, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review
current patch (14.38 KB, patch)
2011-08-15 07:53 PDT, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review
test app plus release exe (40.39 KB, application/zip)
2011-08-15 13:47 PDT, Jim Mathies [:jimm]
no flags Details
NVIDIA Quadro NVS 295 (27.93 KB, text/plain)
2011-10-03 10:46 PDT, Jim Mathies [:jimm]
no flags Details
NVIDIA GeForce GTX 560 Ti (46.47 KB, text/plain)
2011-10-03 11:40 PDT, Darren Kalck [:D-Kalck]
no flags Details
NVIDIA GeFore 9600M GT (26.61 KB, text/plain)
2011-10-03 14:28 PDT, [Baboo]
no flags Details
NVIDIA GeForce GTX 580 (53.82 KB, text/plain)
2011-10-03 15:41 PDT, Emanuel Hoogeveen [:ehoogeveen]
no flags Details
NVIDIA GeForce GT 335M (26.46 KB, text/plain)
2011-10-04 15:19 PDT, juan becerra [:juanb]
no flags Details
simple d3d9 demo (3.21 MB, application/zip)
2011-10-05 09:30 PDT, Jim Mathies [:jimm]
no flags Details
D3D10 IE PIXlog (1.44 MB, application/zip)
2012-01-31 14:16 PST, Jim Mathies [:jimm]
no flags Details
D3D9 testapp PIXlog (19.37 KB, application/zip)
2012-02-02 03:29 PST, Jim Mathies [:jimm]
no flags Details
D3DFlickerTest.zip (9.28 KB, application/zip)
2012-02-10 06:50 PST, Jim Mathies [:jimm]
no flags Details
D3D9 Flicker Workaround (2.32 KB, patch)
2012-02-22 23:29 PST, Bas Schouten (:bas.schouten)
no flags Details | Diff | Splinter Review
FullWindowRenderTest.cpp (5.46 KB, text/plain)
2012-02-23 03:44 PST, Jim Mathies [:jimm]
no flags Details
resize testcase (3.18 KB, patch)
2012-02-28 02:42 PST, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review
Video of working(?) D3DFlickerTest (167.77 KB, video/webm)
2012-09-20 19:04 PDT, Justin Dolske [:Dolske]
no flags Details
roll up (67.81 KB, patch)
2012-09-21 03:40 PDT, Jim Mathies [:jimm]
no flags Details | Diff | Splinter Review

Description Jim Mathies [:jimm] 2011-07-20 11:44:11 PDT
Created attachment 547183 [details]
test app
Comment 1 Jim Mathies [:jimm] 2011-07-20 11:45:35 PDT
A little background – this shows up with the patches in bug Bug 590945 applied to trunk. Originally I figured the problem I’m seeing was the result of a bug in my patches, but after a great deal of testing I’ve come to the conclusion this is either :

1) a bug in Windows
2) a bug in the order / way we render using D3D9 and 10

At a basic level the patches in bug 590945 handle the WM_NCCALCSIZE event and set the desired client area equal to the window area which allows us to render to the entire window surface. The simplest way to accomplish this is to not do any processing in calc size:

calc size params:

// before:
// rgrc[0]: the proposed new window coordinates
// rgrc[1]: the current window cordinates
// rgrc[2]: the source client area coordinates
// pncsp->lppos: move/size data
// after:
// rgrc[0]: the new client coordinates
// rgrc[1]: the client destination coordinates
// rgrc[2]: the client source coordinates

If rgrc[0] remains unchanged, and we return 0 as the result, Windows will remove all the non-client areas and send us a paint message with an hdc equal to the surface of the window.

Attached is sample, stand alone app that has a “ripped out” version of DeviceManagerD3D9 and SwapChainD3D9. The code doesn’t render anything, it simply clears the surface and swaps the back buffer. I’ve kept as much of the initialization and setup code as I can. The same problem I found with my patches shows up in the sample app.

I’m tempted to submit a support request with MS on this, since I think cause #1 is the most likely. But I figured I better run this past Gfx folks first, maybe you all can spot something obvious I can’t. At the very least please compile the sample and see if you can reproduce. STR:

1) run the app
2) grab an edge and resize the window out as large as possible
3) keep resizing in and out

You should see the flickering where the background (non-painted to surface w/glass) shows through.
Comment 2 Jim Mathies [:jimm] 2011-07-20 13:21:25 PDT
Created attachment 547217 [details]
test app

cleaned sample app.
Comment 3 Jim Mathies [:jimm] 2011-08-03 10:50:38 PDT
Kai suggested on IRC we could try disabling acceleration during resize operations. I'm interested in pursuing that as a possible fix, assuming no one sees any major issues with doing so..
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-08-03 18:08:47 PDT
It should work. You'll want to check carefully how performance is affected, especially when we're doing stuff with canvas and HTML video which may start requiring readback from the GPU.
Comment 5 Jim Mathies [:jimm] 2011-08-11 13:38:29 PDT
Created attachment 552491 [details] [diff] [review]
sizing patch v.1

This worked out pretty well. Our resize performance was never very good with d2d/d3d which is improved by these changes, and of course the flicker problem is fixed. The big trick was detecting start and end of the resize which is hit or miss on windows, but the combination wm_sizing events, a timer, and a check of the mouse state seems to do the trick. 

I took this for a spin on some of the ie9 demos, it behaves as expected. Performance drops during the resize then ticks back up as soon as you release the mouse.

I'll have try builds in a bit.
Comment 6 Jim Mathies [:jimm] 2011-08-12 02:56:53 PDT
try builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-007935287928

I need to update this slightly to address a case where users resize the window prior to the toolkit delayed accel timer firing, and cases where callers request a persistent layer backend.
Comment 7 Jim Mathies [:jimm] 2011-08-12 03:24:16 PDT
Created attachment 552627 [details] [diff] [review]
sizing patch v.2

updates:
- deal with early resize prior to sAllowD3D9 being flipped
- ignore layers created with LAYER_MANAGER_PERSISTENT
- always flush layer manager after the resize completes
Comment 8 Bas Schouten (:bas.schouten) 2011-08-12 03:54:11 PDT
Does this work at all when there's a canvas being used? At the very least it'll make it very slow. It should work I guess, with readback.

IE9 demo's actually slow down while resizing on normal builds, so that doesn't mean much. Note that the canvas should remain accelerated in this situation so any additional slowdown should only be due to read back.

What happens with the font cache since this would essentially make us switch from DirectWrite, to GDI, and back to DirectWrite, presumably font rendering would go through all kinds of nasty fallback paths?

Additional concerns would be the recreation of the D3D10 device upon finishing the resize, an operation which takes in the order of milliseconds, and create a device that may be incompatible with any allocated canvases. (although they should probably hit some readback scheme that should still work)

Note that persistent layer manager usage doesn't 'really' work here, as the layer manager is still recreated, and users of that API don't -actually- get a persistent layer manager at all, since they'll end up with a new one now after resize.

A quick investigation with the try-server build also indicates the window is never actually returned to D3D10 layers (just by using about:support). Indeed if I try and use it on FishIE tank at 1000 fish. The canvas simply goes white at resize and remains that way.

On the upside there does seem to be a little perf increase in resizing though (as expected), or at least what happens to the new area when upsizing looks a little prettier in GDI than with D3D10.

I'm pretty sure my list of concerns is much longer than this

Also what did MS have to say on this? I've only got my laptop here but your sample app runs super-smooth for me (that is, if it's meant to show a smooth, resizing, purple rectangle with a wide glass margin). Resizing is so smooth actually, I feel I should profile what makes firefox slow. I'll try and address the bug if hardware at home reproduces the problem as this hack would make me extremely unhappy (sorry for not speaking up earlier, I seem to have lost track of this bug). If we do need to implement this hack, let's figure out on which hardware this bug occurs and strictly implement it there.
Comment 9 Jim Mathies [:jimm] 2011-08-12 05:26:35 PDT
(In reply to Bas Schouten (:bas) from comment #8)
> Does this work at all when there's a canvas being used? At the very least
> it'll make it very slow. It should work I guess, with readback.
> 

Isn't this why we have LAYER_MANAGER_PERSISTENT? This is set on layers created for Canvas via nsContentUtils's PersistentLayerManagerForDocument, AFAICT.

> What happens with the font cache since this would essentially make us switch
> from DirectWrite, to GDI, and back to DirectWrite, presumably font rendering
> would go through all kinds of nasty fallback paths?

Not sure but I'll see if I can track down an answer.

> Additional concerns would be the recreation of the D3D10 device upon
> finishing the resize, an operation which takes in the order of milliseconds,
> and create a device that may be incompatible with any allocated canvases.
> (although they should probably hit some readback scheme that should still
> work)

Seems this is unavoidable. I might be able to cache the layer manager in use temporarily. This is a little tricky with our existing startup delay. Overall though a millisecond restart after a resize shouldn't be a major issue, it's unlikely they'll do much else with the window immediately after resizing, which offers enough time for the device to reset unnoticeably.
 
> 
> Note that persistent layer manager usage doesn't 'really' work here, as the
> layer manager is still recreated, and users of that API don't -actually- get
> a persistent layer manager at all, since they'll end up with a new one now
> after resize.

I need to fix that, OnWindowSizing() should check the persistent state of the layer first.

> 
> A quick investigation with the try-server build also indicates the window is
> never actually returned to D3D10 layers (just by using about:support).
> Indeed if I try and use it on FishIE tank at 1000 fish. The canvas simply
> goes white at resize and remains that way.

That's fixed in v.2 patch, I'll have a new try server build here in a few hours.

> Also what did MS have to say on this? I've only got my laptop here but your
> sample app runs super-smooth for me (that is, if it's meant to show a
> smooth, resizing, purple rectangle with a wide glass margin). Resizing is so
> smooth actually, I feel I should profile what makes firefox slow. I'll try
> and address the bug if hardware at home reproduces the problem as this hack
> would make me extremely unhappy (sorry for not speaking up earlier, I seem
> to have lost track of this bug). If we do need to implement this hack, let's
> figure out on which hardware this bug occurs and strictly implement it there.

As far as MS goes, I haven't taken this to them (yet). Do you feel we should or just try to deal with this internally?

In your testing, did you resize the window out to a very large size and waver back and forth? You should see a flickering. If not, you're one of the few people who hasn't reproduced this yet. :) I've tested on vmware with a forced accel, my laptop, and my desktop, and I see it every time. It's most noticeable 
with large windows.
Comment 10 Jim Mathies [:jimm] 2011-08-12 05:35:24 PDT
Actually it looks like BaseWidget already support the idea of flipping to a basic layer manager on the fly via AutoUseBasicLayerManager. So maybe I can make use of that in flipping back and forth.
Comment 11 Jim Mathies [:jimm] 2011-08-12 12:07:28 PDT
Another try build should be up in a few hours:

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-cf20166887da/

For testing purposes this build has a pref that turns the resize feature on and off @ "gfx.enableresizequirk". This defaults to true (enabled). There's no observer so you have to restart for changes to take effect.

I find resize performance improves quite a bit with this feature on. Something about GDI on my system that handles resizing the rendering surface better.

This should also make it easy to reproduce the paint bug which shows up clearly in fx proper with the patches in bug 590945 applied.
Comment 12 Jim Mathies [:jimm] 2011-08-15 07:53:27 PDT
Created attachment 553175 [details] [diff] [review]
current patch
Comment 13 Jim Mathies [:jimm] 2011-08-15 08:43:28 PDT
I'm doing some testing with nsHTMLMediaElement's today and noticed some odd behavior. One thing I've noticed is we request LAYER_MANAGER_PERSISTENT after the initial layer is setup, which my current fix will ignore. Also independent of the fix I've posted here, displaying webm video in a tab generates a lot of these asserts:

###!!! ASSERTION: Nv3DVStreaming Nv3DVControl failed: 'rv', file f:/Mozilla/firefox/mc/gfx/layers/d3d9/Nv3DVUtils.cpp, line 150

###!!! ASSERTION: mFramesWithLayers out of sync: '!props.Get(DisplayItemDataProperty())', file f:/Mozilla/firefox/mc/layout/base/FrameLayerBuilder.cpp, line 677

which doesn't seem good.

This is the test case I'm working with:

http://www.mozilla.com/en-US/firefox/video/

Will keep investigating..
Comment 14 Bas Schouten (:bas.schouten) 2011-08-15 08:50:40 PDT
(In reply to Jim Mathies [:jimm] from comment #9)
> (In reply to Bas Schouten (:bas) from comment #8)
> > Also what did MS have to say on this? I've only got my laptop here but your
> > sample app runs super-smooth for me (that is, if it's meant to show a
> > smooth, resizing, purple rectangle with a wide glass margin). Resizing is so
> > smooth actually, I feel I should profile what makes firefox slow. I'll try
> > and address the bug if hardware at home reproduces the problem as this hack
> > would make me extremely unhappy (sorry for not speaking up earlier, I seem
> > to have lost track of this bug). If we do need to implement this hack, let's
> > figure out on which hardware this bug occurs and strictly implement it there.
> 
> As far as MS goes, I haven't taken this to them (yet). Do you feel we should
> or just try to deal with this internally?

Yes we should! This patch (if needed) is absolutely terrible!

> 
> In your testing, did you resize the window out to a very large size and
> waver back and forth? You should see a flickering. If not, you're one of the
> few people who hasn't reproduced this yet. :) I've tested on vmware with a
> forced accel, my laptop, and my desktop, and I see it every time. It's most
> noticeable 
> with large windows.

I tried my different machines, I see a very occasional black flicker on one of my NVidia machines (GT230M). Nothing on my ATI cards.
Comment 15 Jim Mathies [:jimm] 2011-08-15 09:02:38 PDT
(In reply to Bas Schouten (:bas) from comment #14)
> > As far as MS goes, I haven't taken this to them (yet). Do you feel we should
> > or just try to deal with this internally?
> 
> Yes we should! This patch (if needed) is absolutely terrible!

What is terrible about it? We have support in base widget for doing this, we just aren't using it on windows. Clearly we've had a need for it at some point. The fix also improves resize redraw performance on my system. That seems like a pretty big win to me.

> 
> > 
> > In your testing, did you resize the window out to a very large size and
> > waver back and forth? You should see a flickering. If not, you're one of the
> > few people who hasn't reproduced this yet. :) I've tested on vmware with a
> > forced accel, my laptop, and my desktop, and I see it every time. It's most
> > noticeable 
> > with large windows.
> 
> I tried my different machines, I see a very occasional black flicker on one
> of my NVidia machines (GT230M). Nothing on my ATI cards.

That sounds like what I'm seeing. Although it's not occasional for me, it's pretty much constant. I have a cinema display and it's most noticeable at window widths > 2000. Unfortunately I haven't had any luck making a recording of it. Screen capture software seems to fix the problem.
Comment 16 Brian R. Bondy [:bbondy] 2011-08-15 09:17:53 PDT
With your test app I see the purple background flicker every 2-3 seconds as I am resizing back and forth.

I do not see any flicker at all in the glass though.

I'm using a MacBook Pro NVIDIA GeForce GT 330M W/ DirecTX 11
Resolution: 1920x1200
Comment 17 Jim Mathies [:jimm] 2011-08-15 12:02:09 PDT
Chatted with bsmedberg about this today, we're going to file off a support request to see if we can get a definitive answer from ms on the cause.
Comment 18 Jim Mathies [:jimm] 2011-08-15 13:47:07 PDT
Created attachment 553256 [details]
test app plus release exe
Comment 19 Bas Schouten (:bas.schouten) 2011-08-15 17:01:53 PDT
(In reply to Jim Mathies [:jimm] from comment #15)
> (In reply to Bas Schouten (:bas) from comment #14)
> > > As far as MS goes, I haven't taken this to them (yet). Do you feel we should
> > > or just try to deal with this internally?
> > 
> > Yes we should! This patch (if needed) is absolutely terrible!
> 
> What is terrible about it? We have support in base widget for doing this, we
> just aren't using it on windows. Clearly we've had a need for it at some
> point. The fix also improves resize redraw performance on my system. That
> seems like a pretty big win to me.

The fact we recreate layer managers and associated resources. The whole point is of drawing to be consistent. Not switching back between different modes, as we move forward and we want layer managers to do things like off main-thread composition and persistent, layers driven animation through user-interaction, etc. Switching them on resizes will make everything harder in the future. At the very least it should only be a temporary solution.

Fwiw, the fact that resize redraw performance becomes better on your system is bad, we should profile where the time is spent in the D3D case and try to fix it :( (I'm worried it might be texture recreation, in which case there might not be much we can do - except reuse textures in a smarter manner). We shouldn't need to spend so much time there as your test app resizes quite smooth even on my slower machines.

> 
> > 
> > > 
> > > In your testing, did you resize the window out to a very large size and
> > > waver back and forth? You should see a flickering. If not, you're one of the
> > > few people who hasn't reproduced this yet. :) I've tested on vmware with a
> > > forced accel, my laptop, and my desktop, and I see it every time. It's most
> > > noticeable 
> > > with large windows.
> > 
> > I tried my different machines, I see a very occasional black flicker on one
> > of my NVidia machines (GT230M). Nothing on my ATI cards.
> 
> That sounds like what I'm seeing. Although it's not occasional for me, it's
> pretty much constant. I have a cinema display and it's most noticeable at
> window widths > 2000. Unfortunately I haven't had any luck making a
> recording of it. Screen capture software seems to fix the problem.

I should note for me only the content flickers, not the glass, just in case that wasn't clear.
Comment 20 bogas04 2011-08-19 09:18:33 PDT
Nightly is Firefox 9 now , Bug 590945 is blocked majorly by this one, will it make it to fx9?
Comment 21 Jim Mathies [:jimm] 2011-08-19 09:20:44 PDT
(In reply to bogas04 from comment #20)
> Nightly is Firefox 9 now , Bug 590945 is blocked majorly by this one, will
> it make it to fx9?

Hard to say at this point, we're still trying to figure out if this is a problem on our end or in Windows. We are working on it though.
Comment 22 bogas04 2011-08-19 19:41:14 PDT
Thanks :)
Comment 23 [Baboo] 2011-08-20 11:03:11 PDT
(In reply to Jim Mathies [:jimm] from comment #9)
> > What happens with the font cache since this would essentially make us switch
> > from DirectWrite, to GDI, and back to DirectWrite, presumably font rendering
> > would go through all kinds of nasty fallback paths?
> 
> Not sure but I'll see if I can track down an answer.

What about simply toggling gfx.font_rendering.directwrite.enabled? It controls whether DW rendering is used when D2D is off (of course only where DW is supported).
Comment 24 Bas Schouten (:bas.schouten) 2011-08-22 17:59:20 PDT
(In reply to [Baboo] from comment #23)
> (In reply to Jim Mathies [:jimm] from comment #9)
> > > What happens with the font cache since this would essentially make us switch
> > > from DirectWrite, to GDI, and back to DirectWrite, presumably font rendering
> > > would go through all kinds of nasty fallback paths?
> > 
> > Not sure but I'll see if I can track down an answer.
> 
> What about simply toggling gfx.font_rendering.directwrite.enabled? It
> controls whether DW rendering is used when D2D is off (of course only where
> DW is supported).

Reloading all the fonts in a different API is bad and probably IO intensive. More importantly this pref isn't actually live and doesn't clear the font cache at this point I believe.
Comment 25 Thomas Gladdines 2011-08-29 08:13:34 PDT
Also keep in mind windows explorer has the same problem on my 64bit system with a nvidia gt220 and also a gt440 it's just less noticeable since it's not so flickering that much as on firefox.
Comment 26 Fede 2011-09-24 13:07:17 PDT
I don't want to bother you, I'm just asking.
What's the status of this bug?
Will be fixed soon?
again I'm just asking
Comment 27 Jim Mathies [:jimm] 2011-09-28 09:16:48 PDT
(In reply to Fede from comment #26)
> I don't want to bother you, I'm just asking.
> What's the status of this bug?
> Will be fixed soon?
> again I'm just asking

We are still working with ms on this, but generally, it seems there is no fix, it's a problem in Windows and our most likely solution will be to implement a work around such as the resize patch I've already posted. I'm currently waiting on clarification on what we need to avoid doing to avoid experiencing the bug. It seems they may not have a solid answer to that.

One thing they did note was that there are some video cards / drivers that do not exhibit the problem. Although again I have little information on why that is as I still have not received a definitive answer as to the root cause of the problem.
Comment 28 Jim Mathies [:jimm] 2011-10-03 10:43:09 PDT
I'm looking for drivers/cards that do or don't exhibit the flicker problem. Thus far I know it's reproducible on

NVIDIA GeForce GT 330M W/ DirecTX 11
NVIDIA Quadro NVS 295
NVIDIA GT230M

Bas, you mentioned your ATI card didn't have the problem. Can you post the detail on your card?

Anyone else tuned in who has a D3D card we support, please take the test app for spin:

https://bugzilla.mozilla.org/attachment.cgi?id=553256

and report back if you see the flicker while resizing.
Comment 29 Jim Mathies [:jimm] 2011-10-03 10:46:27 PDT
Created attachment 564245 [details]
NVIDIA Quadro NVS 295
Comment 30 Jim Mathies [:jimm] 2011-10-03 10:47:24 PDT
Also, if you have the dxdiag tool available, please post the "Save all information" report here as an attachment.
Comment 31 Darren Kalck [:D-Kalck] 2011-10-03 11:40:38 PDT
Created attachment 564275 [details]
NVIDIA GeForce GTX 560 Ti

The background color of the window flickers when I resize the window of the test app.
Comment 32 [Baboo] 2011-10-03 14:28:50 PDT
Created attachment 564336 [details]
NVIDIA GeFore 9600M GT

NVIDIA GeFore 9600M GT

Sporadic flickering.
Comment 33 Emanuel Hoogeveen [:ehoogeveen] 2011-10-03 15:36:23 PDT
NVIDIA GeForce GTX 580, Windows 7 x64 w/ SP1 and latest DirectX redist, driver version 285.38 beta. I see occasional flickering to a dark color (probably black), which appears to get much less frequent when the window is close to the full size of my desktop.
Comment 34 Emanuel Hoogeveen [:ehoogeveen] 2011-10-03 15:41:34 PDT
Created attachment 564360 [details]
NVIDIA GeForce GTX 580

Oh, and here's my dxdiag output (sorry about bugspam).
Comment 35 juan becerra [:juanb] 2011-10-04 15:19:52 PDT
Created attachment 564684 [details]
NVIDIA GeForce GT 335M

I can see flickering in this configuration on the nightly.

NVIDIA GeForce GT 335M
Comment 36 juan becerra [:juanb] 2011-10-04 15:56:17 PDT
I tried a couple more machines in the lab, but none of them met the hardware requirements.
Comment 37 Jim Mathies [:jimm] 2011-10-05 09:30:09 PDT
Created attachment 564883 [details]
simple d3d9 demo
Comment 38 Jim Mathies [:jimm] 2011-10-14 07:48:07 PDT
Posting notes here based on discussions with ms:

1) Generally the flicker problem is related to discarding swap chains (D3D9) or resizing swap chain buffers (D3D10).

2) There is no simple work around, the problem relates to issues with card drivers which do not support this well.

3) While removing all of the non-client chrome tends to make the problem worse / more noticeable, the same side effect has been reproduced with client chrome. Which tends to back up the idea that this is not a problem specific to removing non-client chrome. I've experienced resize performance problems with our current setup on a couple cards (one blacklisted, one not), so I think there is merit to this.

We have a possible fix posted here which turns off acceleration off when we resize. Bas mentioned we might be able to use this for D3D9 but not 10. I don't think we want two different personas rendering behaviors based on hidden settings, so I'm inclined to say implementing the work around based on the D3D version probably isn't a very good idea.

Ms suggested finding other ways to handle resizing that don't involve discarding or resizing buffers on the fly. I've reached my limit of understanding of D3D to go at this beyond what I've already done. If anyone else would care to take this up and experiment, please do. 

Also, Dao has asked that since this work appears to be stalled, we work on fixing a related bug (bug 618353) to improve the experience independent of full skinning. I think that's a good idea so I'll start in on that soon.
Comment 39 Francisco 2011-10-14 11:29:35 PDT
Jim:

There's something I still can't understand. Does this bug occurs just in W7 (as it's said on top) or it's present in XP and Mac, Linux, etc?
Comment 40 Jim Mathies [:jimm] 2011-10-14 12:13:28 PDT
(In reply to Francisco from comment #39)
> Jim:
> 
> There's something I still can't understand. Does this bug occurs just in W7
> (as it's said on top) or it's present in XP and Mac, Linux, etc?

I haven't tested the test app on XP, if someone would like to do that it would help add another data point. Generally this is windows only, specifically windows 7 with dwm enabled.
Comment 41 Francisco 2011-10-14 12:20:01 PDT
Thank you Jim for your answer. I have a machine with XP loaded. Maybe I could check (if I don't have to compile..)
Comment 42 Jim Mathies [:jimm] 2011-10-14 12:25:46 PDT
(In reply to Francisco from comment #41)
> Thank you Jim for your answer. I have a machine with XP loaded. Maybe I
> could check (if I don't have to compile..)

Actually you would have to build it locally, and remove the dwm lib hard links. The existing exe won't load with it's current configuration. I'll see if I can work up an xp compat build.
Comment 43 Fede 2011-11-19 08:31:39 PST
Again I'm just asking, becouse the last comment is from a month ago.
So the question is, is there a solution, or a way to fix it?
Or will you post builds to test? I really want to see this bug fixed, I think that with this we will have a lots of ways to customize Firefox.
So please don't give up with it.
Comment 44 henryfhchan 2011-12-24 22:48:55 PST
Sorry bugspam, can this be fixed so 590945 can proceed and redo the themeing on windows?  Firefox looks horrible on Windows XP with the button on compared to the smooth integration of window bar and chrome in Chromium.
Comment 45 [not reading bugmail] 2012-01-28 16:35:53 PST
(In reply to Jim Mathies [:jimm] from comment #17)
> Chatted with bsmedberg about this today, we're going to file off a support
> request to see if we can get a definitive answer from ms on the cause.

Just curious, has Ms followed up on this?
Comment 46 Jim Mathies [:jimm] 2012-01-30 08:58:17 PST
(In reply to Dennis "Dale" Y. [:cuz84d] from comment #45)
> (In reply to Jim Mathies [:jimm] from comment #17)
> > Chatted with bsmedberg about this today, we're going to file off a support
> > request to see if we can get a definitive answer from ms on the cause.
> 
> Just curious, has Ms followed up on this?

Yes they basically said the way we handle back buffers during resize is unreliable, and that we should look for a better way of handling it.
Comment 47 Bas Schouten (:bas.schouten) 2012-01-31 08:09:19 PST
Just as a note on my ATI card, I'd need to retest, but I think it was just really really rare on my ATI, not completely absent.
Comment 48 Bas Schouten (:bas.schouten) 2012-01-31 08:12:29 PST
(In reply to Jim Mathies [:jimm] from comment #38)
> Posting notes here based on discussions with ms:
> Ms suggested finding other ways to handle resizing that don't involve
> discarding or resizing buffers on the fly. I've reached my limit of
> understanding of D3D to go at this beyond what I've already done. If anyone
> else would care to take this up and experiment, please do. 

I can't experiment right now, and I don't have a lot of ideas on D3D9 (I mean - this -is- their API for resizing buffers, they're saying it's not the right way to resize buffers? Maybe it shouldn't be called ResizeBuffers then?)

On D3D10 one idea I'd have is try creating the new SwapChain first, presenting the new one and only then releasing the old one. I have no idea if that actually helps though! But it might be worth a shot, that way there shouldn't be any time without an active swap chain presented.
Comment 49 Jim Mathies [:jimm] 2012-01-31 08:33:27 PST
Is there a way we can instrument the D3D10 calls in IE to see how they solved this internally? The sup[port guy I worked with was not very helpful. His only solution was to stretch that last frame out during a resize - clearly not an option.
Comment 50 Bas Schouten (:bas.schouten) 2012-01-31 09:34:53 PST
(In reply to Jim Mathies [:jimm] from comment #49)
> Is there a way we can instrument the D3D10 calls in IE to see how they
> solved this internally? The sup[port guy I worked with was not very helpful.
> His only solution was to stretch that last frame out during a resize -
> clearly not an option.

There's a tool called PIXWin in the DirectX SDK you can use to generate a D3D call trace from IE.
Comment 51 Jim Mathies [:jimm] 2012-01-31 13:06:30 PST
(In reply to Bas Schouten (:bas) from comment #50)
> (In reply to Jim Mathies [:jimm] from comment #49)
> > Is there a way we can instrument the D3D10 calls in IE to see how they
> > solved this internally? The sup[port guy I worked with was not very helpful.
> > His only solution was to stretch that last frame out during a resize -
> > clearly not an option.
> 
> There's a tool called PIXWin in the DirectX SDK you can use to generate a
> D3D call trace from IE.

Took a shot at this, but it seems the tool only monitors the first process it creates, and with IE, secondary processes appear to be handling rendering of content. Tried disabling protected mode as well, but this didn't disable ie's multi-process features.
Comment 52 Robert Strong [:rstrong] (use needinfo to contact me) 2012-01-31 13:39:25 PST
Sent to jimm on irc in case it helps (putting in this bug for reference)
http://blog.smartbear.com/post/10-06-01/web-testing---disabling-multiple-processes-of-internet-explorer-8/
Comment 53 Jim Mathies [:jimm] 2012-01-31 14:16:31 PST
Created attachment 593214 [details]
D3D10 IE PIXlog

Here's a log for about:blank being resized in and out. First resize starts in frame 2. It appears that they do call ResizeBuffers in each frame.
Comment 54 Jim Mathies [:jimm] 2012-01-31 14:32:45 PST
I'm not seeing much of an ordering difference here but there are certainly finer differences in the way the two browsers do things. The other obvious difference is that we are accelerating the entire window, including glass, where as ie is working with a child window.

Bas, if you have the time I'd appreciate any feedback you can give on that log data.
Comment 55 Robert Strong [:rstrong] (use needinfo to contact me) 2012-02-01 14:51:24 PST
Thanks Jim for diving into this. Could you also attach the PIXWin log for Firefox when it exhibits this bug (assumes it would be for about:blank being resized in and out) to compare the IE log with?

For those following along, the new theme work has started back up and this bug blocks bug 590945 which is needed for the new theme work.

https://wiki.mozilla.org/Firefox/Features/Theme_Refinement_and_Evolution_%28Australis%29

Jim, assuming we aren't doing anything drastically different than IE do you think it would be worthwhile to get MS to look at a Firefox and IE PXWin log to get their input on what we should be doing differently since their own apps appear to use ResizeBuffers?
Comment 56 [not reading bugmail] 2012-02-02 00:51:19 PST
I do see flicker when resize in the purple to black on my ATI 5450 but not in the glass.  

Maybe you've seen this already, but here an interesting read non the less on using D3D Swap chains and ResizeBuffers here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb206356%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/bb205075%28v=vs.85%29.aspx#Handling_Window_Resizing
Comment 57 Jim Mathies [:jimm] 2012-02-02 03:25:01 PST
(In reply to Robert Strong [:rstrong] (do not email) from comment #55)
> Thanks Jim for diving into this. Could you also attach the PIXWin log for
> Firefox when it exhibits this bug (assumes it would be for about:blank being
> resized in and out) to compare the IE log with?

It would probably be simpler to write a D3D10 test app similar to the D3D9 test app attached here. The D3D9 test app reproduces the flicker while also baking the entire process we go through down into about fifteen calls. I can try to work something like that up.

> Jim, assuming we aren't doing anything drastically different than IE do you
> think it would be worthwhile to get MS to look at a Firefox and IE PXWin log
> to get their input on what we should be doing differently since their own
> apps appear to use ResizeBuffers?

The original support request was for D3D9, so we could open one for D3D10. Before doing that though we would need a test app. It would also probably be good to have someone like Bas open the request and carry the conversation, as I was unable to make any headway with the guy I worked with.
Comment 58 Jim Mathies [:jimm] 2012-02-02 03:29:11 PST
Created attachment 593784 [details]
D3D9 testapp PIXlog
Comment 59 Jeff Gilbert [:jgilbert] 2012-02-09 19:20:32 PST
It looks like changing the SwapEffect to _DISCARD from _COPY, increasing BackBufferCount to 2, and not specifying PresentationInterval, and there doesn't seem to be any flickering anymore.

After resizing for a while, I'm getting D3DERR_OUTOFVIDEOMEMORY, even though I seem to be releasing everything fine.
Comment 60 Jeff Gilbert [:jgilbert] 2012-02-09 21:58:40 PST
After playing around trying to repro this, it looks like it's clean of flickers if we hold off on releasing the old swap chain until we have the new one. (It's hard to tell though, since it's not easy to repro)

(Guess time:) This could be the driver releasing the old chain, and freeing it, before creating the new chain, but the refresh/paint hits right between freeing and creation. In this case, holding on to the old chain until we have the new one in place may help/fix this.
Comment 61 Jeff Gilbert [:jgilbert] 2012-02-09 22:05:21 PST
Using http://pastebin.mozilla.org/1481439 , if someone can repro with '#define HOLD_OLD_CHAIN	0', but not '#define HOLD_OLD_CHAIN	1', then we'll have something.
Comment 62 Jim Mathies [:jimm] 2012-02-10 06:50:54 PST
Created attachment 596042 [details]
D3DFlickerTest.zip

Hate to bring bad news, but with 

#define HOLD_OLD_CHAIN	1

I'm still seeing the flicker, primarily when the window is expanded out near the size of the desktop. 

Attached is my project w/release exe. Maybe some other people cc'd in here can take this for a spin and help confirm.
Comment 63 Bas Schouten (:bas.schouten) 2012-02-10 08:05:05 PST
Looking at the code in the pastebin, those clauses with both always pass, so even if HOLD_OLD_CHAIN is defined it will still release early.

You need to #if !defined(HOLD_OLD_CHAIN) as #if !HOLD_OLD_CHAIN will always pass if HOLD_OLD_CHAIN is valid I believe. If my C++ isn't too rusty that is.
Comment 64 Bas Schouten (:bas.schouten) 2012-02-10 13:28:28 PST
(In reply to Bas Schouten (:bas) from comment #63)
> Looking at the code in the pastebin, those clauses with both always pass, so
> even if HOLD_OLD_CHAIN is defined it will still release early.
> 
> You need to #if !defined(HOLD_OLD_CHAIN) as #if !HOLD_OLD_CHAIN will always
> pass if HOLD_OLD_CHAIN is valid I believe. If my C++ isn't too rusty that is.

jgilbert makes the valid point that if you actually define HOLD_OLD_CHAIN to 1. it does work, that's not what I did, but I guess it is what Jimm did, so that's not at fault.
Comment 65 [not reading bugmail] 2012-02-13 22:46:03 PST
(In reply to Jeff Gilbert [:jgilbert] from comment #60)
> After playing around trying to repro this, it looks like it's clean of
> flickers if we hold off on releasing the old swap chain until we have the
> new one. (It's hard to tell though, since it's not easy to repro)
> 
> (Guess time:) This could be the driver releasing the old chain, and freeing
> it, before creating the new chain, but the refresh/paint hits right between
> freeing and creation. In this case, holding on to the old chain until we
> have the new one in place may help/fix this.

What about using FLIP instead of Discard?  Looks like Discard take more video memory.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172612%28v=vs.85%29.aspx
Comment 66 Bas Schouten (:bas.schouten) 2012-02-22 18:20:10 PST
I've investigated this bug, it seems I can make it go away by adding a ::DwmFlush immediately after the present calls. However, timing measurements I did also revealed this call may take up to 20ms to complete (i.e. a full frame).

We could do this if we do some stuff off the main thread possibly, but it's not going to be too pretty, I'll look into this a little more, but it does provide us with a clear hint of where the problem might roughly be, I'd appreciate it if Jimm or someone else could confirm my findings on other hardware.
Comment 67 Bas Schouten (:bas.schouten) 2012-02-22 18:23:53 PST
Fwiw, a very short sleep, of for example 3ms also makes the problem disappear on my hardware, which makes this even more interesting.
Comment 68 Bas Schouten (:bas.schouten) 2012-02-22 18:35:16 PST
More interesting information: When I set DWMWA_NCRENDERING_POLICY to DWMNCRP_DISABLED, the bug becomes much easier to reproduce. ::DwmFlush then still prevents it from occurring -most- of the time, but it does still occasionally happen, suggesting that adding any time after 'present' just makes the bug less likely to occur.

This might mean that a lot of subsequent presents with different sized swap chains trigger this behavior, as adding any blockage will simply reduce the presentation frequency.
Comment 69 Bas Schouten (:bas.schouten) 2012-02-22 18:39:43 PST
Interestingly enough, when enabling v-syncing, making blocking on v-sync occur in the present call, I'm measuring similar timings at when using ::DwmFlush, however this does -not- reduce the occurrence of the bug. Even though in theory there should be a similar reduction in presentation frequency. This suggests that blocking our main thread for sufficiently long after completion of the present call is the reason the bug is reduced in frequency.
Comment 70 Bas Schouten (:bas.schouten) 2012-02-22 18:51:53 PST
Hrm, the flickering from DWMNCRP_DISABLED seems to be of significantly different origin than the one we're seeing when on ENABLED or on WINDOWSTYLE. So the two are likely not, or only very vaguely related, ::DwmFlush still appears to prevent the issue from occurring for the flickering we care about though, whereas vsync does not.
Comment 71 Jim Mathies [:jimm] 2012-02-22 19:07:26 PST
Bas, is your testing on D3D9 or 10? I tried the DWMFlush call in the D3D9 test app ('test app plus release exe') and didn't see much improvement.
Comment 72 Bas Schouten (:bas.schouten) 2012-02-22 19:11:21 PST
(In reply to Jim Mathies [:jimm] from comment #71)
> Bas, is your testing on D3D9 or 10? I tried the DWMFlush call in the D3D9
> test app ('test app plus release exe') and didn't see much improvement.

I'm testing D3D9, note that this is -after- the Present Call. However I've now found a way to make the bug much easier to reproduce, I run FishIE in the background at maximum fish, making sure my computer is nice and busy (presumably my GPU is the culprit), when doing this I can easily reproduce the bug.

DwmFlush in that case makes things a lot better (as does any blockage after Present it seems, but it doesn't make the problem go away.
Comment 73 Bas Schouten (:bas.schouten) 2012-02-22 20:48:23 PST
Alright, so I disabled all the DWM stuff and still saw the issue, now I seem to have found the strangest workaround, I changed the NCCALCSIZE code into the following:

          if (wParam) {
            params->rgrc[1].left = params->rgrc[1].right = params->rgrc[1].bottom = params->rgrc[1].top = 0;
            params->rgrc[2].left = params->rgrc[2].right = params->rgrc[2].bottom = params->rgrc[2].top = 0;
            return WVR_VALIDRECTS;
          } else {
            params->rgrc[0].left += 1;
            params->rgrc[0].right -= 1;
            params->rgrc[0].top += 1;
            params->rgrc[0].bottom -= 1; /* */
            params->rgrc[1].left = params->rgrc[1].right = params->rgrc[1].bottom = params->rgrc[1].top = 0;
            params->rgrc[2].left = params->rgrc[2].right = params->rgrc[2].bottom = params->rgrc[2].top = 0;
            return 0;
          }

The very first frame now obviously has the client area drawn around it, however every subsequent frame is drawn fine, and no flicker, even under high GPU load, I tried switching back and forth several times but it really seems a lot better on my hardware for some mysterious reason. Could you confirm, Jimm?
Comment 74 Bas Schouten (:bas.schouten) 2012-02-22 23:29:04 PST
Created attachment 599896 [details] [diff] [review]
D3D9 Flicker Workaround

I had to update to a VS2010 project to work on this, so here's the workaround patch that should apply to the D3DFlickerTest on the bug, with it the flicker problem appears to have gone away, I've made it so the initial frame is also shown correctly.
Comment 75 Jim Mathies [:jimm] 2012-02-23 03:44:19 PST
Created attachment 599944 [details]
FullWindowRenderTest.cpp

Fix added to the original D3D9 test app.

So the good news is this reduced the flicker problem on my system *substantially*, although I still occasional experienced it. When I see it is when the window (on a cinema display) encompassed most of the desktop. Smaller windows don't have the issue. For testing purposes I grab the resize corner on the lower right of the window, size out to the lower right corner of the desktop and then hover in a circular or mirrored 'L' pattern slowly.

I can merge the original work in bug 590945 to tip and add this fix to all top level windows if folks want to take a try build for a spin.

The two problems we had there were the flicker problem and redraw performance on resizing. This change definitely seems to help the flickering problem, not sure about resize perf.

Speaking of which, we really need a talos test that measures paint performance while resizing the window. I might try to work something like that up.
Comment 76 Bas Schouten (:bas.schouten) 2012-02-23 08:15:56 PST
(In reply to Jim Mathies [:jimm] from comment #75)
> Created attachment 599944 [details]
> FullWindowRenderTest.cpp
> 
> Fix added to the original D3D9 test app.
> 
> So the good news is this reduced the flicker problem on my system
> *substantially*, although I still occasional experienced it. When I see it
> is when the window (on a cinema display) encompassed most of the desktop.
> Smaller windows don't have the issue. For testing purposes I grab the resize
> corner on the lower right of the window, size out to the lower right corner
> of the desktop and then hover in a circular or mirrored 'L' pattern slowly.

I don't own a cinema display (i.e. nothing bigger than 1920x1200), but I cannot do anything to reproduce the problem there. When turning on FishIE with a lot of fish, straining my system I can very easily see it without the workaround. I have decent hopes this will fix it sufficiently to not make it a blocker for the user experience. People will generally not resize their windows near 'full-screen' size I think, and not many people own screens as big as a a cinema display.

> 
> I can merge the original work in bug 590945 to tip and add this fix to all
> top level windows if folks want to take a try build for a spin.
> 
> The two problems we had there were the flicker problem and redraw
> performance on resizing. This change definitely seems to help the flickering
> problem, not sure about resize perf.

Our resize perf is suboptimal with hardware acceleration in general, I'm not sure there's a lot of regression there. I did a lot of measuring on the test program, and it seems that while normal present calls last ~0.01ms, present calls during resize tend to last 5-15ms or when the GPU is under load even 15-25ms. This is in the testcase we have here that does practically no work, and presumably very hard to avoid. Presumably OMTC when working on windows will help a lot here as that cost will no longer be incurred on the main thread preventing real drawing work from happening.
Comment 77 Jim Mathies [:jimm] 2012-02-27 13:07:30 PST
Posted try builds with all the work in 590945 plus the following fix:

https://hg.mozilla.org/try/rev/6b343c26d0dc

There was no need to mess with width/height since we don't show the window until we've set new dimensions, both of which happen way after we call create.

Note, in a local release build I still see modest flickering.

Once try posts the builds, I'd appreciate any feedback people can give. (It helps to have a persona installed for testing too.)
Comment 78 Mozilla RelEng Bot 2012-02-27 17:46:17 PST
Try run for 5d01a2f652a1 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=5d01a2f652a1
Results (out of 17 total builds):
    exception: 2
    success: 1
    warnings: 1
    failure: 13
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-5d01a2f652a1
Comment 79 Jim Mathies [:jimm] 2012-02-27 18:13:55 PST
(In reply to Mozilla RelEng Bot from comment #78)
> Try run for 5d01a2f652a1 is complete.
> Detailed breakdown of the results available here:
>     https://tbpl.mozilla.org/?tree=Try&rev=5d01a2f652a1
> Results (out of 17 total builds):
>     exception: 2
>     success: 1
>     warnings: 1
>     failure: 13
> Builds (or logs if builds failed) available at:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.
> com-5d01a2f652a1

There was a crashing bug in the fix so I've resubmitted - 

https://tbpl.mozilla.org/?noignore=0&tree=Try&rev=12945a065e6d
Comment 80 Mozilla RelEng Bot 2012-02-28 02:31:17 PST
Try run for 12945a065e6d is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=12945a065e6d
Results (out of 64 total builds):
    success: 49
    warnings: 11
    failure: 4
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-12945a065e6d
Comment 81 Jim Mathies [:jimm] 2012-02-28 02:42:16 PST
Created attachment 601220 [details] [diff] [review]
resize testcase

Attached is the basis for a new talos that tests paint more accurately than tpaint. It positions a window on the upper right and then resizes it out in 300 steps. This should run ok locally in a nightly as well.

With the latest opt builds I'm seeing about 15% regression in this test compared to nightly. Not sure where that comes from. I'll have to disable various parts of the new code to see if I can track it down.
Comment 82 Jim Mathies [:jimm] 2012-03-07 08:44:28 PST
rstrong asked me to write up a summary so we can figure out next steps. 

We now have try builds with the patches in bug 590945 plus Bas's fix plus a crash fix for that patch.

https://tbpl.mozilla.org/?noignore=0&tree=Try&rev=12945a065e6d

There are some test failures there but other than that the builds run and the ui works as expected. I also worked up a new resize talos test which is posted in bug 731159 (and here). With everything applied I still see flicker issues and about a 15% regression on the resize test, so these patches can’t land yet. (It would be great if others tuned into this bug can report their results.) 

Generally this appears to be a bug in Windows DWM. IE is accelerating their content as well using similar calls, although they use a child window for content. We are attempting to accelerate the entire window with non-client chrome removed. This is where the problem introduces itself. To get around this we could:

1) find a better fix for our existing set up (obviously)
2) use the resize trick posted here (comments 14, 15, and 19 explain why we don’t want to use this)
3) bring back child widgets for content (doubtful)
4) don’t implement these features
5) go back to microsoft support

Per #5, we might want to consider this to try and get confirmation of the cause  (full window accel vs. child window, D3D10 issue vs. 9). Someone from Gfx should probably head that effort up if we go that route.
Comment 83 Fede 2012-03-07 11:55:18 PST
I just going to talk from a consumer and basic developer place.
I think the builds posted are working well, now instead of a white flicker issue, it shows the aero style on the bottom, and that's ok.
Also I started coding a css code for the whole window, and as I said it shows the windows aero style when I resize the window.
Plese get out of your mind the fourth option (I'm just saying), developers will be really grateful to being allow of manipulate the entire window, as well consumers who use personas.
The patchs (again, what I think) are working great.

I hope my opinion helps you guys, thanks and sorry for my English
Comment 84 [not reading bugmail] 2012-03-14 21:33:49 PDT
Hi Jim, can you spin another try build? I'd like to take a look to see how it fairs when you get a chance as these ones have expired on ftp. Thanks.
Comment 85 Mozilla RelEng Bot 2012-03-28 12:32:42 PDT
Try run for 7bcaa6959dd6 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=7bcaa6959dd6
Results (out of 2 total builds):
    success: 2
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmathies@mozilla.com-7bcaa6959dd6
Comment 86 Justin Dolske [:Dolske] 2012-08-09 14:48:53 PDT
Talked with jgilbert, he felt Bas knows more of what to try here. So imma take the liberty of bouncing over.

Bas: Is this something you'll be able to pick up? It's an Australis blocker, so we're hoping to get this in a good state in the current cycle, and target an Austrailis landing in the next cycle.
Comment 88 Justin Dolske [:Dolske] 2012-08-29 17:04:50 PDT
I see the flickering/flashing on my Windows 7 desktop as well. I compared the Try build and current Nightly, each with and without HW Accel.

I took a video of what I found:

  https://people.mozilla.com/~dolske/tmp/bug-672885-c88.mp4

1) The whole window (glass included) will flash black when resizing. Easy to trigger, but seems inconsistent in exactly when or what frequency.

2) Resizing inwards on the left border makes the content bounce rapidly.

3) Resizing outwards from the upper-left corner makes the glass portions rapidly flicker black.

4) When expanding part of the window, the newly-exposed rect flickers with stale pixels or black.

#1 and #3 are the main problems, and only happen with the Try build when using HW Accel. (Nightly flavors are fine).

#2 is a separate bug. Nightly does it, and so do Chrome and IE. Maybe just a hard case to handle or rare enough it's not a concern.

#4 is also a separate bug, and every browser does it. I know we can't show real content (takes time to render, would make resize laggy), but it would be nice if we could prefill it with a fill color (say, page background). That would help a lot, I suspect.
Comment 89 henryfhchan 2012-08-29 21:15:46 PDT
Sorry if this is bugspam, but here's a suggestion:
It seems that #4 is unavoidable, so
one of the things that could be done is delay the resize of the window until it is sure that glass for that new area can be drawn (during resize, a thin line white line appears where there is supposed to be glass, content area black), and then resize chrome/content when mouse is released (with animation?).
This will have an effect of the window border not following exactly under the mouse cursor on older hardware, but that looks more aesthetically pleasing than flashing colors.
(btw the older behavior in Windows XP was to either draw the whole window completely before it was shown on the screen.  It lagged, but it didn't mess up.)
Comment 90 Justin Dolske [:Dolske] 2012-09-20 19:04:58 PDT
Created attachment 663244 [details]
Video of working(?) D3DFlickerTest

Bas asked me to retest with D3DFlickerTest.zip (attachment 596042 [details]), with and without his patch to that (attachment 599896 [details] [diff] [review]). The goal being to make sure that the full-up browser patch I tested in comment 88 was doing the right thing.

I don't seem to be able to reproduce the whole-window flicker with D3DFlickerTest, alas. After building it, I get a resizable purple window... The only issue I see with it is that sometimes the the normal Windows border/control will flash into view. Not sure if that's relevant or not -- but I certainly don't see the whole window flickering black as I did in comment 88.

This video demos what I'm seeing.
Comment 91 Jim Mathies [:jimm] 2012-09-21 03:37:49 PDT
Another try build with border fixes.

https://tbpl.mozilla.org/?noignore=0&tree=Try&rev=7457b0420e00

I'll post a roll up. I confirmed the fix is getting hit. It's in nsWindow::WindowProcInit if anyone would care to test.
Comment 92 Jim Mathies [:jimm] 2012-09-21 03:40:03 PDT
Created attachment 663345 [details] [diff] [review]
roll up
Comment 93 Jim Mathies [:jimm] 2012-09-21 03:43:09 PDT
(In reply to Jim Mathies [:jimm] from comment #92)
> Created attachment 663345 [details] [diff] [review]
> roll up

The changes here really aren't that serious. The heady stuff is in browser css, which needs to form it's own window border. There's also code in theme that handles drawing window borders and corners. Overall though this is pretty easy code to tweak if anyone cares to try.
Comment 94 Justin Dolske [:Dolske] 2012-09-24 15:22:39 PDT
(Confirmed that I'm still seeing issues 1&3 from comment 88 with the try build from comment 91).
Comment 95 Stephen Horlander [:shorlander] 2013-05-02 08:23:51 PDT
I know this bug has proven difficult (impossible?) to fix. However the issue of not being able to draw the full window border is an ongoing eyesore for anyone using Personas. 

With the upcoming Australis theme changes this will also a problem for everyone on XP. The middle of the window/titlebar will have one texture but it will not be seamless with the window border. The customization background texture on all versions also has visible seems left, right and bottom.

Is there any other work around that would possibly work? Or potentially even a fix just for XP and not for accelerated windows on Vista+?

Thank you!
Comment 96 Jared Wein [:jaws] (please needinfo? me) 2013-05-02 10:51:11 PDT
Jim, I was talking with Bas and Dolske today about this patch.

Can we land this patch but include a pref to toggle it? This way if we start to see issues we can easily turn it off while working on a fix (and possibly get more people's attention on it?)
Comment 97 Jim Mathies [:jimm] 2013-05-02 11:55:43 PDT
(In reply to Jared Wein [:jaws] from comment #96)
> Jim, I was talking with Bas and Dolske today about this patch.
> 
> Can we land this patch but include a pref to toggle it? This way if we start
> to see issues we can easily turn it off while working on a fix (and possibly
> get more people's attention on it?)

This work changes the outer layout of the main browser window in browser.xul. I don't know of any way you can pref something like that.
Comment 98 Jim Mathies [:jimm] 2013-05-02 11:58:20 PDT
(In reply to Jim Mathies [:jimm] from comment #97)
> (In reply to Jared Wein [:jaws] from comment #96)
> > Jim, I was talking with Bas and Dolske today about this patch.
> > 
> > Can we land this patch but include a pref to toggle it? This way if we start
> > to see issues we can easily turn it off while working on a fix (and possibly
> > get more people's attention on it?)
> 
> This work changes the outer layout of the main browser window in
> browser.xul. I don't know of any way you can pref something like that.

Actually, were you talking about the full window frame patch or the resizing fix?
Comment 99 Jared Wein [:jaws] (please needinfo? me) 2013-05-02 12:24:22 PDT
I was talking about the full window frame patch. Is this something that we can land and then backout if we find that the flickering is affecting too many people?
Comment 100 Jim Mathies [:jimm] 2013-05-02 12:48:58 PDT
(In reply to Jared Wein [:jaws] from comment #99)
> I was talking about the full window frame patch. Is this something that we
> can land and then backout if we find that the flickering is affecting too
> many people?

You could but I think a lot of people are going to see problems. I've been through two nvidia cards that both had the problem since I first started working on this. 

What we could consider is landing the fall back to GDI during resize patch to see what impact it has. That patch solved the problem completely. Gfx folks would have to sign off on that first though.
Comment 101 Jared Wein [:jaws] (please needinfo? me) 2013-05-02 12:57:00 PDT
Bas, can you sign off on what comment #100 is proposing?
Comment 102 Bas Schouten (:bas.schouten) 2013-05-02 13:34:37 PDT
(In reply to Jared Wein [:jaws] from comment #101)
> Bas, can you sign off on what comment #100 is proposing?

No, I can not, I think it's too risky.
Comment 103 Bas Schouten (:bas.schouten) 2013-05-02 13:35:43 PDT
(In reply to Jared Wein [:jaws] from comment #101)
> Bas, can you sign off on what comment #100 is proposing?

Fwiw, I also think it's too fiddly. I'll have another look at why the resize fix isn't working somewhere next week hopefully. Since everyone I've spoken to has reported it works fine in the stand-alone test app it would be interesting to see why it doesn't seem to work fore firefox.
Comment 104 Matthew N. [:MattN] (PM me if requests are blocking you) 2014-03-29 17:42:08 PDT
Jimm, could you clarify what parts of bug 590945 cause this flicker? IIUC, it's setting the chromemargin such that the whole window is drawn by us (with no native frame). Is that all or is it related to some of the other changes in that bug? (I'm not familiar enough with the Windows APIs to understand the test app).

Do we know if this still occurs with D3D11(.1)? If not, I think we could consider implementing bug 590945 for Windows 8+. Thoughts?
Comment 105 henryfhchan 2014-03-29 19:15:42 PDT
I have an ATI Radeon HD 5450, on Windows 7.  The test app flickers black and purple, while the  D3DFlickerTest.zip is completely smooth.  Setting chromemargin to any arbitrary number doesn't cause any black flickering on my system as far as I can tell...
Comment 106 Jim Mathies [:jimm] 2014-04-21 06:29:09 PDT
(In reply to Matthew N. [:MattN] from comment #104)
> Jimm, could you clarify what parts of bug 590945 cause this flicker? IIUC,
> it's setting the chromemargin such that the whole window is drawn by us
> (with no native frame).

That seemed to be the root cause. The test apps cooked this down so it wasn't anything unique to the mozilla gfx code. I think in general we're trying to do something here that is uncommon that's unexpected/untested by gfx driver vendors.

I'm also sure it's driver specific. For example I currently can't reproduce in the same system I used two years ago having replaced the gfx card last year.

> Is that all or is it related to some of the other
> changes in that bug? (I'm not familiar enough with the Windows APIs to
> understand the test app).
> 
> Do we know if this still occurs with D3D11(.1)? If not, I think we could
> consider implementing bug 590945 for Windows 8+. Thoughts?

No idea. Worth testing. I still have the original gfx card that I know reproduces the issue if you want me to ship it someplace for testing.

New card (can't reproduce):

Card name: NVIDIA GeForce GTX 660 Ti
Manufacturer: NVIDIA
Chip type: GeForce GTX 660 Ti
Driver Version: 9.18.13.3165

Older cards that reproduced (based on comments):

NVIDIA GeForce GT 330M W/ DirecTX 11
NVIDIA Quadro NVS 295
NVIDIA GT230M
NVIDIA GeForce GTX 560 Ti
NVIDIA GeFore 9600M GT
NVIDIA GeForce GTX 580
NVIDIA GeForce GT 335M
ATI 5450
Comment 107 Bas Schouten (:bas.schouten) 2014-04-21 06:58:19 PDT
(In reply to Jim Mathies [:jimm] from comment #106)
> (In reply to Matthew N. [:MattN] from comment #104)
> New card (can't reproduce):
> 
> Card name: NVIDIA GeForce GTX 660 Ti
> Manufacturer: NVIDIA
> Chip type: GeForce GTX 660 Ti
> Driver Version: 9.18.13.3165
> 
> Older cards that reproduced (based on comments):
> 
> NVIDIA GeForce GT 330M W/ DirecTX 11
> NVIDIA Quadro NVS 295
> NVIDIA GT230M
> NVIDIA GeForce GTX 560 Ti
> NVIDIA GeFore 9600M GT
> NVIDIA GeForce GTX 580
> NVIDIA GeForce GT 335M
> ATI 5450

Let's not rule out timing here, for me this became a lot easier to reproduce on larger screens, suggesting timing was relevant. Your new card could simply be so much faster it doesn't obviously reproduce anymore.
Comment 108 Jim Mathies [:jimm] 2014-04-21 07:07:02 PDT
Good point, I've been testing on a cinema display at 2560 x 1600 which makes it easier to reproduce with my old gfx card. It appears to be an issue with the present call failing to flush all bits to the screen in time for display.
Comment 109 Bas Schouten (:bas.schouten) 2014-04-21 07:49:58 PDT
Unassigning since I'm not currently doing any work on this and leaving it assigned to me will just cause false impressions.
Comment 110 henryfhchan 2014-04-29 21:34:31 PDT
To clarify, on my ATI 5450 Firefox never flickers black and purple once, but the test app does.  Is it sure that the test app is doing exactly what Firefox is doing?
Comment 111 Jim Mathies [:jimm] 2014-04-30 01:57:47 PDT
(In reply to henryfhchan from comment #110)
> To clarify, on my ATI 5450 Firefox never flickers black and purple once, but
> the test app does.  Is it sure that the test app is doing exactly what
> Firefox is doing?

The test app is doing something we would like to do in firefox but currently don't due to this bug. That's the reason why we worked up the test app in the first place.
Comment 112 Johan C 2015-01-24 10:03:08 PST
Did you ever look at the way they fixed this problem in Chrome?
Chrome bug: https://code.google.com/p/chromium/issues/detail?id=305432
Commit: https://chromium.googlesource.com/chromium/src/+/b5e2a733b00cfc62f9f9380087ae9227f93ea0d3
Diff: https://chromium.googlesource.com/chromium/src/+/b5e2a733b00cfc62f9f9380087ae9227f93ea0d3%5E!/

It sounds like the same problem, apologies if I'm wrong. :)
Comment 113 Johan C 2015-01-24 10:31:26 PST
(In reply to Jim Mathies [:jimm] from comment #62)
> Created attachment 596042 [details]
> D3DFlickerTest.zip
The .exe in this testcase is smooth as butter on a GTX 470, which I believe is an earlier card than some of the cards mentioned above. Could it have been fixed in a recent gpu driver or Windows patch?
Comment 114 Jared Wein [:jaws] (please needinfo? me) 2015-01-26 10:59:43 PST
(In reply to Johan C from comment #112)
(In reply to Johan C from comment #113)
Comment 115 Jim Mathies [:jimm] 2015-01-26 11:20:00 PST
(In reply to Johan C from comment #113)
> (In reply to Jim Mathies [:jimm] from comment #62)
> > Created attachment 596042 [details]
> > D3DFlickerTest.zip
> The .exe in this testcase is smooth as butter on a GTX 470, which I believe
> is an earlier card than some of the cards mentioned above. Could it have
> been fixed in a recent gpu driver or Windows patch?

Seems likely if you can't reproduce it anymore. I'm two cards removed from the original device I was testing on in 2011 so I can't go back and test without installing the old card, updating the diriver and testing. Not something I have the time for currently.
Comment 116 Bas Schouten (:bas.schouten) 2015-02-04 17:54:45 PST
(In reply to Johan C from comment #112)
> Did you ever look at the way they fixed this problem in Chrome?
> Chrome bug: https://code.google.com/p/chromium/issues/detail?id=305432
> Commit:
> https://chromium.googlesource.com/chromium/src/+/
> b5e2a733b00cfc62f9f9380087ae9227f93ea0d3
> Diff:
> https://chromium.googlesource.com/chromium/src/+/
> b5e2a733b00cfc62f9f9380087ae9227f93ea0d3%5E!/
> 
> It sounds like the same problem, apologies if I'm wrong. :)

The symptoms would be similar :). But the actual cause for us is different. We're dealing with an as of yet not completely understood windows bug (that might be gone in more recent windows versions). We'd mainly need to find a work-around, but to the best of my knowledge this is not a priority for us at the moment.

Note You need to log in before you can comment on or make changes to this bug.