[OS X] [OpenGL] Painting errors while resizing window using nsIWidget::Resize, causing Preferences window to flicker when switching between preference tabs

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
Graphics
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: mstange, Assigned: mstange)

Tracking

Trunk
mozilla2.0b8
All
Mac OS X
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

Attachments

(2 attachments)

(Assignee)

Description

8 years ago
Created attachment 475821 [details]
flicker during preferences window animation

When Gecko causes a window to be resized to a smaller size, the window briefly shows garbage. This can be reproduced in the preferences window by switching panes, or using by typing javascript:resizeTo(800,600) into the URL bar (and allowing JavaScript to resize existing windows).

I can't reproduce the bug using the native window resizer, so it's probably something in nsCocoaWindow::Resize - maybe we're changing mBounds at the wrong time or something like that.
(Assignee)

Updated

8 years ago
blocking2.0: --- → ?
When do we run into this?
(Assignee)

Comment 2

8 years ago
When switching between panes in the Firefox preferences window, for example.
I see some white flickering when we the preferences window gets smaller. The precise behaviour probably depends on OS X version or driver or something.

Matt, would you like to look into this?
Assignee: nobody → matt.woodrow+bugzilla
blocking2.0: ? → final+
(Assignee)

Updated

8 years ago
Summary: [OS X] [OpenGL] Painting errors while resizing window using nsIWidget::Resize → [OS X] [OpenGL] Painting errors while resizing window using nsIWidget::Resize, causing Preferences window to flicker when switching between preference tabs
(Assignee)

Updated

8 years ago
Duplicate of this bug: 602234
Duplicate of this bug: 604398

Comment 7

8 years ago
I see the same in Thunderbird trunk (32bit) if I change from one tab to another in the preferences.
OS: Mac OS X → Windows 7

Updated

8 years ago
OS: Windows 7 → Mac OS X
Not sure if I know enough about cocoa for this.

The garbage happens approximately here:

#0  0x00007fff82e539e2 in mach_msg ()
#1  0x00007fff819232af in -[NSSurface setFrame:] ()
#2  0x00007fff81922d9c in -[NSSurface syncToViewUnconditionally] ()
#3  0x00007fff81924c8d in -[NSSurface syncToView:] ()
#4  0x00007fff8182ff51 in -[NSView _invalidateGStatesForTree] ()
#5  0x00007fff8182fc98 in -[NSView _invalidateFocus] ()
#6  0x00007fff8182a682 in -[NSView setFrameSize:] ()
#7  0x00007fff8182a19a in -[NSView setFrame:] ()
#8  0x0000000101364ee2 in nsChildView::Resize (this=0x12526dad0, aX=0, aY=0, aWidth=613, aHeight=414, aRepaint=0) at /Users/mattwoodrow/mozilla-central2/widget/src/cocoa/nsChildView.mm:1145
#9  0x0000000100323db5 in DocumentViewerImpl::SetBounds (this=0x1251f6d20, aBounds=@0x1296e4bf0) at /Users/mattwoodrow/mozilla-central2/layout/base/nsDocumentViewer.cpp:1871
#10 0x0000000100fc3b37 in nsDocShell::SetPositionAndSize (this=0x1296e4a20, x=0, y=0, cx=613, cy=414, fRepaint=0) at /Users/mattwoodrow/mozilla-central2/docshell/base/nsDocShell.cpp:4592
#11 0x0000000101092f3f in nsWebShellWindow::HandleEvent (aEvent=0x7fff5fbfa830) at /Users/mattwoodrow/mozilla-central2/xpfe/appshell/src/nsWebShellWindow.cpp:357
#12 0x0000000101349a67 in nsCocoaWindow::DispatchEvent (this=0x12525d7d0, event=0x7fff5fbfa830, aStatus=@0x7fff5fbfa8ec) at /Users/mattwoodrow/mozilla-central2/widget/src/cocoa/nsCocoaWindow.mm:1323
#13 0x000000010134ee20 in nsCocoaWindow::ReportSizeEvent (this=0x12525d7d0, r=0x7fff5fbfa9a0) at /Users/mattwoodrow/mozilla-central2/widget/src/cocoa/nsCocoaWindow.mm:1396
#14 0x000000010134f4bb in nsCocoaWindow::Resize (this=0x12525d7d0, aX=460, aY=163, aWidth=613, aHeight=436, aRepaint=1) at /Users/mattwoodrow/mozilla-central2/widget/src/cocoa/nsCocoaWindow.mm:1148
#15 0x000000010134f2ae in nsCocoaWindow::Resize (this=0x12525d7d0, aWidth=613, aHeight=436, aRepaint=1) at /Users/mattwoodrow/mozilla-central2/widget/src/cocoa/nsCocoaWindow.mm:1177

And then we repaint at the end of nsCocoaWindow::Resize and it renders correctly.

The strip of garbage appears to be about the size that we are reducing the view by. Cocoa native coordinates use 0,0 at the bottom left don't they? Looks like its somehow invalidating the strip along the top that's now no longer part of the view before moving it up.
Duplicate of this bug: 601784
(Assignee)

Comment 10

8 years ago
So the root cause is that we're calling [NSView setFrame:] before the actual NSWindow resize. I think we can just stop doing that.
(Assignee)

Comment 11

8 years ago
Created attachment 492962 [details] [diff] [review]
v1

This backs out most of bug 355177. Calling nsCocoaWindow::Resize now basically comes down to a single [mWindow setFrame:] call, which then goes the same path as regular window resizing caused by dragging the resizer.

The first ReportSizeEvent call can be removed because the comment is no longer true: The NSView won't be briefly shown at a wrong position. It might have at the time when this code was added, but it sure doesn't now - otherwise we'd also see that phenomenon during normal user resizing.

The StartResizing/StopResizing/IsResizing guards can be removed because the ReportSizeEvent call has been removed. The guards prevented windowDidResize from firing a duplicate size event, but in the new world that event will be the only one that's sent.

The second ReportSizeEvent call can be removed because the size event that will be sent by windowDidResize will already carry the right dimensions.

I've pushed this patch to the tryserver, let's see what it says.
Assignee: matt.woodrow+bugzilla → mstange
Status: NEW → ASSIGNED
Attachment #492962 - Flags: review?(joshmoz)
(Assignee)

Comment 12

8 years ago
All tests passed on tryserver.

Updated

8 years ago
Attachment #492962 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 13

8 years ago
http://hg.mozilla.org/mozilla-central/rev/e1983b9db75d
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Backed out for causing crash tests on OSX to go permanently orange.

http://hg.mozilla.org/mozilla-central/rev/1b4041e3c177
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This patch can probably re-land after the tree opens, it looks like it wasn't the cause of the crashtest failures after all.

Comment 16

8 years ago
Relanded:

http://hg.mozilla.org/mozilla-central/rev/1b27facfee00
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED

Updated

8 years ago
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.