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

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Michael]

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.

Comment 1

[Mats Palmgren (inactive)]

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)

Comment 2

[Michael]

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.

Comment 3

[Mats Palmgren (inactive)]

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

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 5

[Michael]

Yup.  That's not what I see.  It's the entire window, including buttons, tabs, etc., that is not painted.

Comment 6

[Joe Drew (not getting mail)]

I see this too. I think/hope that proper double-buffering will fix this.

Comment 7

[Joe Drew (not getting mail)]

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).

Comment 8

[Markus Stange [:mstange]]

No idea, but I'd love to see a video of that bug in action.

Comment 9

[Joe Drew (not getting mail)]

Your wish is my command! http://people.mozilla.org/~jdrew/opengl-no-update.mov

Comment 10

[Michael]

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.

Comment 11

[Markus Stange [:mstange]]

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

Comment 12

[Jonathan Kew [:jfkthame]]

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.

Comment 13

[Joe Drew (not getting mail)]

Attachment: 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.

Comment 14

[Joe Drew (not getting mail)]

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.

Comment 15

[Jonathan Kew [:jfkthame]]

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;

Comment 17

[Markus Stange [:mstange]]

(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.

Comment 18

[Dominic]

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?

Comment 19

[Michael]

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.

Comment 20

[Michael]

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

Comment 22

[Nordware]

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.

Comment 23

[Bob Moss :bmoss]

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).

Comment 24

[Michael Newton]

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.

Comment 25

[Markus Stange [:mstange]]

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.

Comment 26

[Michael Newton]

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.

Comment 27

[Bob Moss :bmoss]

At Bas's suggestion I updated the video driver on my laptop and the problem went away.

Comment 28

[Joe Drew (not getting mail)]

Bob, this is an OS X bug; did you mean to comment on a different bug?

Comment 29

[Bob Moss :bmoss]

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.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Not a false alarm! We should make sure your old driver version is blacklisted.

Comment 31

[Bob Moss :bmoss]

Thanks Roc. Do you guys need anything else from me on this?

Comment 32

[Joe Drew (not getting mail)]

Bob, gonna take this off the bug so as not to clutter it up.

Comment 33

[Joe Drew (not getting mail)]

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.

Comment 34

[Michael]

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

Comment 35

[Michal Urban]

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.

Comment 36

[Drew]

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.

Comment 37

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 38

[Joe Drew (not getting mail)]

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.

Comment 39

[Michal Urban]

@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".

Comment 40

[Drew]

Looks like this actually returned for me with the update to the public build of b10.

Comment 41

[Jeff Muizelaar [:jrmuizel]]

For anyone who can reproduce the problem: Is the rendering fixed when the new window is obscured by another window in front of it?

Comment 42

[Drew]

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).

Comment 43

[Axel Hecht]

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.

Comment 44

[Michal Urban]

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.

Comment 45

[Joe Drew (not getting mail)]

Michal, that implies that your computer has OpenGL layer compositing disabled. Did you turn that off explicitly?

Comment 46

[Michal Urban]

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

Comment 47

[Jeff Muizelaar [:jrmuizel]]

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?

Comment 48

[Axel Hecht]

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.

Comment 49

[Drew]

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.

Comment 50

[Michal Urban]

@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.

Comment 51

[Jeff Muizelaar [:jrmuizel]]

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

Comment 52

[Joe Drew (not getting mail)]

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.

Comment 53

[Joe Drew (not getting mail)]

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.

Comment 54

[Axel Hecht]

I can reproduce on any (of 6).

Comment 55

[Joe Drew (not getting mail)]

Jeff and I agree that this doesn't need beta coverage.

Comment 56

[Drew]

What exactly does that mean?

Comment 57

[Joe Drew (not getting mail)]

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!

Comment 58

[Joe Drew (not getting mail)]

Attachment: workaround

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!

Comment 59

[Josh Aas]

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.

Comment 60

[Markus Stange [:mstange]]

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 61

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 62

[Joe Drew (not getting mail)]

Attachment: workaround v2

Addressed Josh and Markus' comments, and renamed the member variable to mDidDeferredInit to make Jeff happier.

Comment 63

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 64

[Joe Drew (not getting mail)]

http://hg.mozilla.org/mozilla-central/rev/b22b865abf30

Comment 66

[Axel Hecht]

I still see this on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre. :-/

Comment 67

[Michal Urban]

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.

Comment 68

[George Carstoiu]

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?

Comment 69

[Michal Urban]

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!

Comment 70

[Michal Urban]

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.

Comment 71

[George Carstoiu]

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.