Closed Bug 603134 Opened 14 years ago Closed 13 years ago

Minefield does not render any content in new windows until the window is moved

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: notforyourmail, Assigned: joe)

References

()

Details

(Keywords: regression, Whiteboard: rdar://8563279 [hardblocker][was january 20][has patch][needs review jrmuizel, josh])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre

When first started, or when a new window is opened, Minefield renders a blank page.  The window is rendered after 20-30 seconds, or sometimes if another operation causes it to be redrawn, such as moving, resizing, or covering and uncovering the window with another window.

Reproducible: Always

Steps to Reproduce:
1.  Start the latest Minefield build
2.  Current tabs are not shown.  Instead, only a new tab is shown.  After the browser window is forced to repaint itself, the previously open tabs and content appear.
3.  This can also be reproduced sometimes by clicking on a link that opens a new window.
Actual Results:  
Browser fails to paint any content for 20-30 seconds.

Expected Results:  
Content appears normally.

This problem has been present for at least the past week.
Can you find the build where the problem first started?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/
(folders ending in -mozilla-central)
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre)
Gecko/20101003 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre)
Gecko/20101003 Firefox/4.0b7pre

was the first build where I experienced it.  I believe it was fine in all the builds before that.
20101003 was built from http://hg.mozilla.org/mozilla-central/shortlog/54899
I don't see any obvious suspects in that list.
That build works fine for me on my MacBook Pro (old Core2 version).
-> Core/GFX for further triage
blocking2.0: --- → ?
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
Michael, can you please verify that you *don't* see this in 2010-10-02-03-mozilla-central (from link in comment 1)?

That's why you've implied, but as Mats notes, http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=286d3026ae20&tochange=bb18e81ea0f8 doesn't contain anything interesting at all.
Yup.  That's not what I see.  It's the entire window, including buttons, tabs, etc., that is not painted.
I see this too. I think/hope that proper double-buffering will fix this.
Assignee: nobody → joe
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking2.0: ? → betaN+
I was wrong - my double-buffering patch has no effect on this.

Josh/Markus, do you have any idea what would make a window not update until we interact with the titlebar or resize the window? I looked into [ChildView drawRect:] but there doesn't seem to be any explicit dirtying.

Also, strangely, this problem doesn't persist through reboots - it takes a while to come back (although it's fully reproducible once it comes back).
No idea, but I'd love to see a video of that bug in action.
Here's a video showing lots of cases where the bug occurs:

http://wintersnight.org/Video%20for%20bug%20reports/Minefield%20window%20painting%20bug.mov

Ironically, the video, and the one that Joe posted, don't seem to render properly in Minefield.  I just get a white window (I did get one frame of Joe's video).  I had to download both videos directly to view them.
This bug completely baffles me. The only time I've seen something comparable was after removing the glFlush call for bug 593342.

That's a great video, Michael. To summarize:
 - Titlebar painting works fine all the time.
 - It's not that we ignore individual repaints (like "the very next repaint
   after window opening"). Instead, we fall into a not-updating-anything mode
   until something wakes us up from that mode.
 - These wake-ups don't work consistently. Deactivating the window triggered
   a wake-up at 1:10 (when Michael opened System Preferences), but not at
   1:36.

The only explanation that comes to my mind here is "driver bug". :-(

(In reply to comment #5)
> Yup.  That's not what I see.

Does this mean that the bug is not present in this build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-02-03-mozilla-central/firefox-4.0b7pre.en-US.mac64.dmg
I've been seeing this for quite a few days on my own builds (on MacBook Pro, OS X 10.6.4), but I thought it might be something I'd broken locally, or related to doing non-IPC, non-libxul builds. But today I did a more "normal" build (with libxul, ipc, etc) and it's still happening.

My gut feeling was that it might be related to Layers, as it seemed like the usual way to "fix" the problem was to slightly resize the window and I thought this might be triggering re-creation of a top-level layer in the window that was somehow in a broken/invalid state and therefore failing to draw anything.
Attached file standalone testcase
This is a standalone OpenGL testcase, based on an Apple example. It should redraw the window with three different colours at about 15 fps; of course, because of this bug, we only get the first draw until we move the window.
The biggest problem I have is finding a way to reliably reproduce this. If I reboot, the problem goes away; I suspect if we killed and restarted a targeted subset of processes (maybe only the window manager?) we'd also "fix" the problem. If I can say "do this and this and this and this and then the problem occurs" to Apple, we'd have a lot better chance of getting this bug fixed.
FWIW, it's possible to work around the problem for your standalone testcase by calling [[self openGLContext] clearDrawable] and [[self openGLContext] setView:self] on the view *after* it has been initialized, e.g. by setting up a one-shot timer as shown below.

Putting these calls directly into the initWithFrame: method does *not* work.

I don't actually know why this fixes the problem, or how robust it is, but it seems to work in my testing. Maybe there'd be a way to put a comparable workaround into Gecko, if we can't find a more "correct" solution.

*** /Users/jonathan/Downloads/OpenGL-NoUpdate-Bug/DispatchLifeGLView.m.orig	2010-10-14 21:40:51.000000000 +0100
--- /Users/jonathan/Downloads/OpenGL-NoUpdate-Bug/DispatchLifeGLView.m	2010-10-15 13:14:40.000000000 +0100
***************
*** 72,82 ****
--- 72,88 ----
  		[self adjustGLViewBounds];
  
  		[[NSTimer scheduledTimerWithTimeInterval: (1.0f / 15.0) target: self selector:@selector(drawRect:) userInfo:self repeats:true] retain];
+ 		[[NSTimer scheduledTimerWithTimeInterval: 0.0f target: self selector:@selector(deferredInit) userInfo:self repeats:false] retain];
  		
  	}
      return self;
  }
  
+ - (void)deferredInit {
+ 	[[self openGLContext] clearDrawable];
+ 	[[self openGLContext] setView:self];
+ }
+ 
  - (void)drawRect:(NSRect)rect {
  	[[self openGLContext] makeCurrentContext];
          static int val = 0;
Whiteboard: rdar://8563279
Whiteboard: rdar://8563279 → rdar://8563279 [2 days]
Whiteboard: rdar://8563279 [2 days] → [1 week] rdar://8563279
(In reply to comment #14)
> The biggest problem I have is finding a way to reliably reproduce this.

Bug 585663 comment 9 has some steps to reproduce for a phenomenon that sounds very similar to this bug.
I have the exact same problem seen in Joe Drew's video (comment #9). I described it on the mozillazine forums (Post #8): http://cut.gd/1aLK
Basically all new windows are "frozen" untill I move them or some palettes are drawn on a portion of the window. Here is a screen how a new window looks like:
http://img241.imageshack.us/img241/7691/27031346.png
I can leave it all day long that way and nothing happens.
The problem disappears when these two apps are closed:
Displaperture (rounded corners for the menubar)
&
Screenshade (to dimm the brightness of the screen)
Please read my post on the forums for further informations...

Thanks to Joe Drew's "dupilacte bug" report in comment #16 (https://bugzilla.mozilla.org/show_bug.cgi?id=601403) I was able to get firefox working correctly with layers.accelerate-all set to false :D

More infos on my machine:
Macbook Pro (mid 2009) / nVidia 9400 & 9600 / all updates
Firefox beta 7 / tested on blank and new profile
Also tested on my old mbp from 2007 eith nVidia 8600

Why is Mozilla setting hardware accelaration to true as default, when not all graphics cards are supported?
This bug has returned in the latest nightly build (December 18th), and also fails to open the same tabs that you were on when the browser closed.
A note: the rendering problem is present in the latest build on my Mac Pro, but not my Macbook Pro.  The Mac Pro's graphics configuration is:

 Chipset Model:	ATI Radeon HD 4870
  Type:	GPU
  Bus:	PCIe
  Slot:	Slot-1
  PCIe Lane Width:	x16
  VRAM (Total):	512 MB
  Vendor:	ATI (0x1002)
  Device ID:	0x9440
  Revision ID:	0x0000
  ROM Revision:	113-B7710F-176
  EFI Driver Version:	01.00.318


The Macbook Pro's graphics configuration is:
NVIDIA GeForce 8600M GT:

  Chipset Model:	GeForce 8600M GT    
  Type:	GPU
  Bus:	PCIe
  PCIe Lane Width:	x16
  VRAM (Total):	256 MB
  Vendor:	NVIDIA (0x10de)
  Device ID:	0x0407
  Revision ID:	0x00a1
  ROM Revision:	3175
Whiteboard: [1 week] rdar://8563279 → [1 week] rdar://8563279 [hard blocker]
Whiteboard: [1 week] rdar://8563279 [hard blocker] → [1 week] rdar://8563279 [hardblocker]
Whiteboard: [1 week] rdar://8563279 [hardblocker] → rdar://8563279 [hardblocker][january 20]
Appears on Windows XP too. Sometimes content isn't rendered until you move/resize/minimize/maximize the window or change to another tab and back.
I'm seeing similar behavior on Win7 - 64. If I restore a minimized minefield the content doesn't paint until a mouse move message is sent to the window by moving over it. Until then the window is white. 4.0b10pre (2011-01-18).
I haven't seen this issue on my 2007 MacBook for a few weeks now.

  Chipset Model:	GMA 950
  Type:	GPU
  Bus:	Built-In
  VRAM (Total):	64 MB of Shared System Memory
  Vendor:	Intel (0x8086)
  Device ID:	0x27a2
  Revision ID:	0x0003

Currently running http://hg.mozilla.org/mozilla-central/rev/f009b80a465d with HW acceleration enabled.
Michael, did you verify that you're using hardware acceleration by looking at the "GPU Accelerated Windows" row on about:support? It could be that your graphics card has been blacklisted in the meantime.
That was the case, about:support was showing GPU accelerated window count was 0/1. I didn't realize that some chipsets were blacklisted.

However, I have just enabled layers.acceleration.force-enabled and restarted. GPU accelerated window count now shows "1/1 OpenGL" and I still don't experience this bug any more.
At Bas's suggestion I updated the video driver on my laptop and the problem went away.
Bob, this is an OS X bug; did you mean to comment on a different bug?
Joe I wasn't sure if this was from common code or mac only, the behavior was identical to what was being described here. Having said that it turned out, in my case, to be a driver issue so false alarm.
Not a false alarm! We should make sure your old driver version is blacklisted.
Thanks Roc. Do you guys need anything else from me on this?
Bob, gonna take this off the bug so as not to clutter it up.
Dolske just told me that he just saw this bug on his first gen unibody MBP with a GeForce 9400M/9600M GT combination, but he had uptime of 54 days, and he'd never seen the problem before, so it might be much less frequent on that hardware.
Markus: it doesn't seem to be happening to me on more recent builds.  I think at least one machine I was using was added to the hardware blacklist a few days after I posted this.  But the Mac Pro that I noted it happening on does not have blacklisted hardware:

Adapter Description0x21a00,0x20400Vendor ID0000Device ID0000Adapter RAMAdapter DriversDriver VersionDriver DateDirect2D EnabledfalseDirectWrite EnabledfalseWebGL RendererATI Technologies Inc. -- ATI Radeon HD 4870 OpenGL Engine -- 2.1 ATI-1.6.26GPU Accelerated Windows2/2 OpenGL
Just found this report, I filed what looks like a duplicate bug 626407 recently.

I can confirm this still happens with Fx4b9 on my MacBookPro7,1 (NVIDIA GeForce 320M) running OS X 10.6.6. I also have CUDA drivers installed, not sure if/how these affect this issue. Fx 3.6 runs OK on the same config.

On the Mac all core driver updates come with OS updates so there is no way to update independently - I guess most users go with auto SW updates like I do so they are on the latest system.
I filed one of the duplicates of this, but it's been strange actually. I reenabled hardware acceleration and sure enough Firefox was doing what was described. After I gave the computer a restart, I haven't had any problems since.
If anyone can come up with quick steps to reproduce this problem that would be great. Also, it might be worth checking /var/log/windowserver.log to see if it says anything.
Jan 24 15:07:43  [12218] Reserved range exhausted. (0x1bbf6c000 to 0x1bc37f000 goes out of bounds).  Mapping new allocations into any available space
Jan 24 15:08:21  [12218] CGXRunOneEventPass: timed out after 1 events with wait time of 0.010000

It is not causative, but I think I received CGXRunOneEventPass message just before OpenGL applications stopped refreshing without moving the window.
@Jeff: I got this behavior consistently (always) on my 13" 2010 MBP (NVidia 320M) running latest Snow Leopard. Didn't have to do anything special to trigger it. If this is driver/card dependent not all Macs will show it.

However: I'm now trying the first candidate build of Fx4b10 - and the problem seems to be gone! I need to test more but it looks promising - I tried all scenarios reported in bug 626407 and they all work now without window "nudging".
Looks like this actually returned for me with the update to the public build of b10.
For anyone who can reproduce the problem: Is the rendering fixed when the new window is obscured by another window in front of it?
As with the previous build, a restart did fix the problem.

As for windows in front, from what I remember it did to some extent. Any tooltips, menus, or windows in front would make the content behind it render, however I don't think you could interact with it until you moved Firefox itself.

I'm not sure if this was mentioned elsewhere but using Expose will also fix the window (a little faster than moving or resizing).
I'm seeing this both on the nightly and on b10, different profiles. 10.6.5, NVIDIA GeForce GT 330M, 
  Geräte-ID:	0x0a29
  Versions-ID:	0x00a2
(Sorry, don't know the English names, more info on request).

I actually got to fix the behaviour in a broken window by doing a screenshot of it, same for menus overlapping the content, though they only fix it for a limited region around where the menu popped up.

I also get a bunch of 

Wed Jan 26 17:43:41 wokbok.local firefox-bin[42671] <Error>: kCGErrorIllegalArgument: CGSGetScreenRectForWindow

but for all versions of Firefox. I haven't seen Joe's lines from comment 38.

This started to hit me with the nightlies from Friday or so, I don't remember running into it before.
I can now confirm I haven't seen this problem on my Mac since I installed Fx4b10. With previous betas, (obscured part of) a blank Fx window would be repainted if another window was placed over it. Also e.g. command+tab would repaint the middle of the screen only (where running app icons were).

FWIW, my Graphics section of about:support
      
Adapter Description 0x22600,0x20400
Vendor ID0000
Device ID0000
Adapter RAM
Adapter Drivers
Driver Version
Driver Date
Direct2D Enabled false
DirectWrite Enabled false
WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce 320M OpenGL Engine -- 2.1 NVIDIA-1.6.26
GPU Accelerated Windows 0/1

If memory serves, last line was 1/1 before.
Michal, that implies that your computer has OpenGL layer compositing disabled. Did you turn that off explicitly?
I haven't done any tweaks to configuration, beta 10 must behave differently from previous ones here (Mozilla blog mentions "remote blacklisting for hardware acceleration"?). I can try enabling it, how do I do that? In about:config I can see:

layers.acceleration.disabled      default boolean false
layers.acceleration.force-enabled default boolean false
I'd also be interested know what happens if the firefox process is paused before moving the window. Does moving the window still fix the problem?
the window draws with minefield being stuck in gdb. gdb attached to the process, the opened new window via shortkey, the window got stuck, crtl-c in gdb, moved window and painted, but process not responsive, c in gdb, process responsive again.
Well the issue started popping up again and I can indeed say for sure that menus or windows on top will render the content, however it still appears frozen amongst a sea of white. The only real way to get it working is to move the window in some way.

@Michal: I have the same specs there as you, however I'm showing 1/1. Check to see whether "Use hardware acceleration when available" is checked under Preferences > Advanced > General > Browsing.
@Drew: Yes, "Use hardware accel.." was checked, corresponding to layers.acceleration.disabled = false setting. Toggling this value and restarting browser didn't change anything (other that layers.accel.disabled was duly shown as true).

However, setting layers.acceleration.force-enabled to true and restarting brought the problem back, with the last line of about:support changing to:

GPU Accelerated Windows 1/1 OpenGL

So for me, beta 10 doesn't use HW acceleration by default unless it's forced. When forced it brings back the "not refreshed unless moved" behavior.

Other observations:
about:config shows Vendor and Device ID as 0000. These are likely not detected properly as they are 0x10DE and 0x08A0 respectively in System Profiler. Also Adapter RAM, driver/version etc. are not detected.

Direct2D and DirectWrite are obviously Windows only and irrelevant for the Mac. I can imagine it's difficult to support this cross platform. Even Macs have a variety of chipsets/drivers out there, although this must be much worse on Windows... It makes sense that unsupported/untested configs are disabled by default.
I've created a wiki page to collect and organize the information about this bug. If everyone who's experiencing this bug could fill in their details it would help a lot.

https://wiki.mozilla.org/Platform/GFX/NoDrawing
The effect of dragging a window in the foreground over a window in the background that isn't refreshing: http://grab.by/8D8X

I can confirm Axel's observation that moving the window while the program is stopped in gdb still refreshes that window.

Also, switching Spaces while the window is not refreshing causes it to refresh.
I use 4 Spaces normally. When I'm on the first desktop, I can reproduce this bug. When I'm on the second through fourth desktop, I can't.
I can reproduce on any (of 6).
Jeff and I agree that this doesn't need beta coverage.
blocking2.0: betaN+ → final+
What exactly does that mean?
I have a workaround that makes Firefox windows themselves draw again. I applied Jonathan Kew's workaround to Firefox in a naïve way, which didn't work - probably because it got put on the end of the native event queue, then got run before any regular Gecko drawing.

However, inserting it into [ChildView drawRect: inContext:] (along with a guard to ensure it's only run once) makes Firefox draw again.

ChildView isn't the right place, I think - at least, the profile chooser doesn't start drawing again when this is the only place the workaround's in. But this is a hopeful start!
Attached patch workaround (obsolete) — Splinter Review
I was finally able to create a workaround that functions in Firefox by applying Jonathan's workaround on the first draw of our ChildView, instead of on its initialization. This seems to work for everything we draw!
Attachment #508921 - Flags: review?(joshmoz)
Attachment #508921 - Flags: review?(jmuizelaar)
Whiteboard: rdar://8563279 [hardblocker][january 20] → rdar://8563279 [hardblocker][was january 20][has patch][needs review jrmuizel, josh]
Comment on attachment 508921 [details] [diff] [review]
workaround

>                                              object:self];
> 
>+
>   return self;

Don't add another blank line here.

>+// Work around bug 603134.
>+// OS X has a bug that causes new OpenGL windows to only paint once or twice,
>+// then stop painting altogether. By clearing the drawable from the GL context,
>+// and then resetting the view to ourselves, we convince OS X to start updating
>+// again.
>+- (void)deferredInit
>+{
>+  NS_OBJC_BEGIN_TRY_ABORT_BLOCK;
>+
>+  [mGLContext clearDrawable];
>+  [mGLContext setView:self];
>+
>+  NS_OBJC_END_TRY_ABORT_BLOCK;
>+}

This function seems intended to be generic, maybe put the comment in the function above the relevant two lines of code.

>@@ -2751,16 +2770,28 @@ NSEvent* gLastDragMouseDownEvent = nil;
>   if (mGeckoChild->GetLayerManager(nsnull)->GetBackendType() == LayerManager::LAYERS_OPENGL) {
>     LayerManagerOGL *manager = static_cast<LayerManagerOGL*>(mGeckoChild->GetLayerManager(nsnull));
>     manager->SetClippingRegion(paintEvent.region); 
>     if (!mGLContext) {
>       mGLContext = (NSOpenGLContext *)manager->gl()->GetNativeData(mozilla::gl::GLContext::NativeGLContext);
>       [mGLContext retain];
>     }
>     mGeckoChild->DispatchWindowEvent(paintEvent);
>+
>+    // Perform a deferred init the very first time we draw. This works around a
>+    // Mac OS X bug that stops windows updating on OS X when we use OpenGL.
>+    if (mDoDeferredInit) {
>+      [[NSTimer scheduledTimerWithTimeInterval: 0.0f
>+                                        target: self
>+                                      selector: @selector(deferredInit)
>+                                      userInfo: self
>+                                       repeats: false] retain];

We don't put spaces between ":" and the argument in Obj-C messages.
Attachment #508921 - Flags: review?(joshmoz) → review+
Comment on attachment 508921 [details] [diff] [review]
workaround

>+      [[NSTimer scheduledTimerWithTimeInterval: 0.0f
>+                                        target: self
>+                                      selector: @selector(deferredInit)
>+                                      userInfo: self
>+                                       repeats: false] retain];

[self performSelector:@selector(deferredInit) withObject:nil afterDelay:0];
would be shorter.
Comment on attachment 508921 [details] [diff] [review]
workaround

>+
>+  BOOL mDoDeferredInit;
> }

This is a poor name. It's better if object state is property of the object or a constituent part.
Attached patch workaround v2Splinter Review
Addressed Josh and Markus' comments, and renamed the member variable to mDidDeferredInit to make Jeff happier.
Attachment #508921 - Attachment is obsolete: true
Attachment #509187 - Flags: review?(jmuizelaar)
Attachment #508921 - Flags: review?(jmuizelaar)
Comment on attachment 509187 [details] [diff] [review]
workaround v2


> 
>+    mDidDeferredInit = NO;
>+

Please add a comment about why we can't schedule or call the deferredInit function from here.

>     [self setFocusRingType:NSFocusRingTypeNone];
>   }
>   
>   // register for things we'll take from other applications
>   PR_LOG(sCocoaLog, PR_LOG_ALWAYS, ("ChildView initWithFrame: registering drag types\n"));
>   [self registerForDraggedTypes:[NSArray arrayWithObjects:NSFilenamesPboardType,
>                                                           NSStringPboardType,
>                                                           NSHTMLPboardType,
>@@ -2294,16 +2297,31 @@ NSEvent* gLastDragMouseDownEvent = nil;
>                                                name:NSViewGlobalFrameDidChangeNotification
>                                              object:self];
> 
>   return self;
> 
>   NS_OBJC_END_TRY_ABORT_BLOCK_NIL;
> }
> 
>+- (void)deferredInit
>+{

maybe give this a better name than deferredInit, like clearAndReset drawable.

>+  NS_OBJC_BEGIN_TRY_ABORT_BLOCK;
>+
>+  // Work around bug 603134.
>+  // OS X has a bug that causes new OpenGL windows to only paint once or twice,
>+  // then stop painting altogether. By clearing the drawable from the GL
>+  // context, and then resetting the view to ourselves, we convince OS X to
>+  // start updating again.

Also add a comment about how this can cause flashing.
Attachment #509187 - Flags: review?(jmuizelaar) → review+
Depends on: 631339
http://hg.mozilla.org/mozilla-central/rev/b22b865abf30
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I still see this on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre. :-/
In Fx4b11, my experience is unchanged from b10: - by default acceleration is disabled, but when I force enable it the drawing refresh issue is back.

Interestingly, SeaMonkey 2.1b2 accelerates by default on the same HW, and I need to disable acceleration to remove the refresh issue.
Depends on: 644494
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre

I can longer reproduce the issue. Michael, do you have clear steps to reproduce in order to see whether this bug was fixed or not?
My previous input was based on betas 10 & 11, I tested again with the final Fx4.0 on the same system (only Mac OS X is now up to 10.6.7).

Now, acceleration seems to work as expected:

- even without forcing acceleration is reported to work (1/1 OpenGL) when enabled
- when forced, nothing changes since it's working by default
- in both cases the redraw issue is gone, no need to "nudge" windows anymore

So I'm happy to report it appears to be fixed!
I just realized that the tests above were done in the 64-bit mode which I started to use recently. My original reports were based on 32-bit mode.

I re-tested with 32-bit with following results:

- without forcing acceleration is not working (0/1 reported) although it's enabled
- forcing makes acceleration work
- in both cases the redraw issue is gone

This still means that the rendering bug is fixed, there remain some peculiarities around GPU acceleration.
Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110405 Firefox/4.2a1pre

Based on Comment 69 and Comment 70 I am changing issue to Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.