377060 - Preferences window blanks during resize

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Dave Townsend [:mossop]]

Since bug 355177 made the resizing nice and smooth, the preferences window now goes completely blank during the resize. It looks fairly poor and when there is very little resizing to be done it has a horrible flicker like effect.

Comment 1

[Josh Aas]

Yeah, I meant to file this bug. Because of the way Gecko draws content doing anything else is very difficult, but since I wrote that patch we have changed a lot of our gfx code. We might be able to do something about that now.

Comment 2

[Dave Townsend [:mossop]]

I've taken a look at iTunes' preferences and that also blanks on resize, but it looks far nicer. There are two key differences between what it does, and what we do.

First our window blanks to complete white. iTunes blanks to the preferences background (kind of grey stripes). This is far less of a change, its really only the actual widgets disappearing than the entire window changing.

Second the pane selector at the top and the buttons at the bottom do not disappear in iTunes. I wonder if there's a way to do something similar with our window.

Comment 3

[Dave Townsend [:mossop]]

This looks really sucky, it'd be nice to at least decide if we can/cant do something here

Comment 4

[Colin Barrett [:cbarrett]]

Attachment: proposed fix

Here's my proposed fix.

It's not entirely perfect -- ideally we'd want the toolbar header to remain, but the subview to remain hidden. Not sure that's possible, though.

This *does* gets rid of the white flash though. Instead of white, we show the window background (kind of a stripey texture). It looks a good deal better.

While doing an animated resize, the view gets called to redraw continuously. Am I right in guessing the reason why we don't just let this happen is that this results in bad mojo for Gecko? There's code in there to stop the redraws from happening.

Comment 5

[Dave Townsend [:mossop]]

This is much better I agree. But I also agree that keeping the header would be good.

On a technical note maybe I'm misreading but it looks like we now force the background to a set colour. Im guessing this is going to cause problems with other windows that may have whatever freakish colours they have. Can we not just make the background the background colour of the current window or is this a problem that the background of the preferences is some special style, I note DOMi claims it is white.

Comment 6

[Colin Barrett [:cbarrett]]

The appearance of the background of the prefs window you see is determined by the -moz-appearance property. That's where those pinstripes get painted.

Effort in trying to develop a bunch of heuristics to be better at setting the background color to match funky windows with odd background colors would probably be best redirected to allowing repaints to fire during a resize.

Is the issue that we don't get callbacks of the resize as it's happening? That can be done quite easily if we use an NSViewAnimation (which, despite the name, also operates on windows). Josh?

Comment 8

[Josh Aas]

NSViewAnimation looks promising, it wasn't available to me before because it is 10.4+. Colin, can you investigate the possibility of using that and drawing during the animation before I finish reviewing your other patch?

As for "proposed fix", it definitely looks better but maybe not good enough. We might want to just turn off all animation instead of doing that.

Comment 9

[Colin Barrett [:cbarrett]]

(In reply to comment #8)
> NSViewAnimation looks promising, it wasn't available to me before because it is
> 10.4+. Colin, can you investigate the possibility of using that and drawing
> during the animation before I finish reviewing your other patch?
> 
> As for "proposed fix", it definitely looks better but maybe not good enough. We
> might want to just turn off all animation instead of doing that.

I tried it out in just "blocking" mode a while back, which resulted in a similar behavior to not hiding the content view.

I didn't try using it in non-blocking or threaded mode, though. Here's an idea: what if we set up a delegate and called ReportSizeEvent() multiple times? I might go ahead and try that out. It's pretty simple to do.

It seemed to me though that any time we tried to draw while resizing Gecko would get really upset and crash.

Comment 10

[Colin Barrett [:cbarrett]]

This will be fixed by bug 393117.

Comment 12

[Josh Aas]

fixed by bug 393117