84574 - Mac OS X: Windows dragging is SLOW

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[zs98]

Dragging Mozilla windows around is unbearably slow.  This bug first appeared in
build 6/5/01 of Fizzilla.  Previously, dragging was in line with the rest of the OS.

Comment 1

[meiering]

Checked this out with QuartzDebug (application in the OSX dev tools). In the 6/5
build "live window resizing" is functional for the first time by default. The
problem appears to be that other carbon apps only use quartz to draw window
contents when resizing windows, make dropshadows, etc. but window dragging is
drawn by the GPU, not the CPU. In 6/5 quartz updates the entire window when
dragging, thus the massive slowdown.

fire up quartzdebug /MacOSX/Developer/Applications/QuartzDebug.app and compare
Fizz to other carbon apps.

Comment 2

[Adam]

But other Carbon apps have native interfaces. I wouldn't be surprised if this
was a side-effect of XUL.

Mac OS X is so slow that I'm not sure this will be a high-priority problem
anytime soon. But it is a problem (compared to dragging an IE window of the same
size around) so I'm going to confirm this.

Comment 3

[Simon Fraser [no longer active]]

So this is a regression from the live window resizing? Over to pink

Comment 4

[Mike Pinkerton (not reading bugmail)]

are we talking about moving windows or resizing them? we don't even get notified
when the windows are being moved, so i'm not quite sure how the resize code
could be getting involved.

Comment 5

[Mike Pinkerton (not reading bugmail)]

i have a patch to this. it appears that i wasn't checking the appropriate
parameter so the live-resize code was kicking in even when the window was moving.

Comment 6

[Mike Pinkerton (not reading bugmail)]

Attachment: [patch] only invalidate on resize, not move

Comment 7

[Mike Pinkerton (not reading bugmail)]

Attachment: [patch #2] the real patch, ignore the other one

Comment 8

[Mike Pinkerton (not reading bugmail)]

r=pchen

Comment 9

[Simon Fraser [no longer active]]

I think only invalidating the area that differs between the two sizes is not 
enough. Resizing the window can cause the page to re-layout in a different way, 
necessitating an entire-window invalidate.

Comment 10

[Mike Pinkerton (not reading bugmail)]

Attachment: [patch #3] go back to invalidating the whole window

Comment 11

[Simon Fraser [no longer active]]

sr=sfraser on attachment 37975 [details] [diff] [review]

Comment 12

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 13

[Mike Pinkerton (not reading bugmail)]

fixed.

Comment 14

[Chris Petersen]

Marking verified in the June 13th build (2001061314)