The bug described by 6245040, a delay during maximization, has returned.
###@###.### 2005-05-27 14:53:22 GMT
Comments
EVALUATION
More data.
Here's some numbers with a test that mimicks SwingSet2's internal frames. The test maximizes, the restores a frame the size of SwingSet2 n times, where n is specified via -max n.
Following where measured on Shannon's desktop machine, which is an AMD box with a GeForce4 MMX 440 with AGP8X.
Maximization animation on
1.5
-max 10 3469
-max 20, 6547
1.6
-max 10 = 4600
-max 10 no buffer per window = 3500
-max 10, no aa=4422
-max 10, no aa, no buffer per window, 3422
-max 10, no aa, 4187
-max 10, no aa, no buffer per window, 3516
-max 20, no aa, no buffer per window=6469
-max 20, no aa=8141
Results at 1024x768
1.5
-max 20, 6219
1.6
-max 20, no aa, 7469
-max 20, no aa, no buffer per window, 7594
Turning off maximization animation.
1.5
-max 20, 1375
1.6
-max 20, no aa, 2890
-max 20, no aa, bufferPerWindow=false, 1390
My laptop (IBM Thinkpad t42p (ati fire gl t2)), maximization animation off, AA on
1.5
-max 20 1302
1.6
-max 20 2700
-max 20, no aa 1540
-max 20, no aa, no buffer per window=1462
Kathy's laptop (Dell Precision M20), maximization animation on, LCD on
1.5
-max 1, 484
-max 10, 3500
1.6
-max 1, 700
-max 1, no aa, 515
-max 1, no aa, no buffer per window=515
-max 10, 4400
-max 10, no aa, 3500
-max 10, no aa, no buffer per window=3500
As you can see, Shannon's desktop appears to be an annomaly. In particular the bulk of the slow down on Shannon's machine appears to be in the extra cost associated with buffer per window in creating a new back buffer at each window size. On other machines that isn't the case. The biggest impact is the cost of using AA text. When you turn off any font smoothing the times drop to roughly that of 1.5.
As Shannon's machine appears to be an anomally, and the extra overhead on his machine is smallish (80-100ms) per maximization, and enabling buffer per window has a lot of goodness I'm closing this out.
20-04-2006
EVALUATION
I've definitively convinced myself maximization is slower, but as far as I can tell it isn't because of the gray rect fix, rather other things. I focused on SwingSet2 with windows look and feel (XP) and Stylepad with Metal. Here's my finding:
SwingSet2
In all cases I tested by launching SwingSet2, waiting for it to load everything, switching to windows look and feel, and then maximizing. Shannon said this is the slowest case, so that it's the one I focused on.
In 1.5 the windows look and feel did not cache anything, whenever we needed to draw something we would scale the images as necessary using 2D. In 1.6 when we converted over to using uxtheme for rendering we suddenly needed to render to an offscreen image. Windows rendering now involves creating an offscreen image, using native code to render to that image and then copying the image to the screen. We also added caching logic of the images.
On my machine in 1.5 Swing painting takes roughly 110 milliseconds. In 1.6 that number is roughly 250 milliseconds. Of that time the bulk of it (180 milliseconds) is spent rendering tabbedpane. Why tabbedpane? I think it's a combination of things. For one TabbedPane renders the biggest area, in my case 1600x1041! That's a big image. The caching logic uses SoftReferences. As you can imagine trying to cache such large images will easily take up a lot more heap than we did before and result in more gcs (the images are held by SoftReferences). That's adding to the cost too. When I run with verbosegc you can see a fullgc during maximiation. I don't doubt this adds to the delay as well.
The natural question to ask is whether or not caching is helping us? During maximization that answer really depends. I tried turning off caching, just using a single image that is enlarged based on the area we're rendering to and turned off the accelaration logic Dmitri added. When I run with this I combination see maximization times of ~200ms or ~300ms. As far as I can tell the lower number corresponds to no gc, and the bigger number a full gc. It just so happens that the sequence I tested with may or may not trigger a gc and it isn't very consistant I'm not quite sure why. In other words if we get a full gc, then caching is faster then no caching, if we don't get a full gc then no caching is faster, at least in this test case.
Stylepad
SwingSet2 was tested with windows look and feel, which can be explained by the new rendering path, but what of Stylepad with metal? On my machine Swing rendering for maximization goes from ~ 40ms to ~90ms. As far as I can tell the majority of the additional time is being spent in rendering AA text. Metal now picks up desktop settings, and so by default on XP, if you haven't changed your desktop in anyway, Stylepad will render portions of the text using aa. When I forced this off time dropped down to ~50ms.
At this point Chet has offered to dig a big deeper and see if there is anything else that can be done.