868107 - OSX titlebar drawing glitches

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

Bug 861317 made drawing in the titlebar more efficient by not invalidating the titlebar every time nsChildView::WillPaint() is called.

So things are more efficient, but they're not perfect; there are some cases where the titlebar needs to be invalidated, but it's not happening.

Example, approaching a tab close button from the bottom and hovering causes only half of the hovered sprite icon to be drawn.

JosiahOne has also catalogued some glitches that I think are similar in root cause. I'll include them in this bug next.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Attachment: JosiahOne glitch reports

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: Resize window glitch

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Separator being cut off glitch:

STR:
1) Just keep pressing Cmd-t until there are too many tabs to display in the tab bar.


Tabs arrow scrollbox glitch:

STR:
1) Overflow the tabs
2) Click and hold the tab scroll button twice (Click and hold for half a second, release, and try again). so that the tabs keep sliding over.


Resize button glitch:

1) Start with a window that does not completely fill the screen.
2) Hit the resize button.

The titlebar area should become corrupted-looking. After it is done resizing it will look normal. Resizing back down does not cause the issue.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

I originally thought these were all different manifestations of the same bug, but at least in one case, that's not true.

I've determined that the resize button glitch only shows itself when hardware acceleration is enabled. I suspect this is involved:

http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsChildView.mm#2764

The comment reads:

// We usually don't get here for Gecko-initiated repaints. Instead, those
// eventually call drawUsingOpenGL, and don't go through drawRect.
// Paints that come through here are triggered by something that Cocoa
// controls, for example by window resizing or window focus changes.

// Since our window is usually declared as opaque, the window's pixel
// buffer may now contain garbage which we need to prevent from reaching
// the screen. The only place where garbage can show is in the bottom
// corners - the rest of the window is covered by our OpenGL surface.
// So we need to clear the pixel buffer contents in the corners.

So, that last paragraph is now false, since I believe garbage can now show up in the titlebar. So I think we need to clear the titlebar here as well.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #4)

I'd think carefully about the cost of what you suggest.  We don't want to reintroduce the same kind of problem I fixed in bug 861317.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hm. Perhaps instead of invalidating it each time, we can protect it from having garbage written to it?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Setting nglayout.debug.widget_update_flashing to true is very illuminating. When approaching the tab close button from below, I can see that the correct region is being re-painted.

So I think in this case (as Steven suspected in IRC), it's possible that our widget code just doesn't know to update the sprite in the frame context.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

It should be noted that all of these glitches seem to be fixed by mstange's patch in bug 676241.

Comment 9

[Markus Stange [:mstange]]

Fixed by bug 676241.