Community
Participate
Working Groups
3.3M2, 3.3 presentation enabled The animation is cute but it's currently too slow to be useful on my machine (WinXP SP2, dual 3.2Ghz, 2G memory, Nvidia GeForce 6200, 3 monitors). There's a noticeable pause (2-3 sec?) when it captures the screen before it starts scaling it down. javaw.exe (jdk1.5.0_06) takes close to 50% of the CPU during this period, i.e., close to 100% of a single CPU.
The same is true on my machine, the wait is between one and two seconds and I guess it's the capturing of the screen contents. I have Windows XP, Pentium 4 with 3.0GHz, Intel 82865G graphics, one monitor with 1600x1200 pixels.
Thanks for the feedback Ed. I've been working on this (see bug 156445). Also note that there's also a defect that greatly affects the -initial- minimize that causes all views to be 'activated' (causing all sorts of plugin loading...). If we can't get an acceptable speed I'll give it up but capturing the current bits has some true advantages since it makes the animation match the operation; we're here, do this...it's happening...we're there. I find the current animation style weird because we do the operation and then the animation tries to catch up... Also, we've -gotta- be able to do something more than early 80's style black rects...I can't -believe- that a box capable of rendering multi-100K polygon games at 50 frames a second can't do better. That being said the guidelines I'm using to determine 'acceptable' are startup time <75 ms and a 40ms frame rate minimum. This gives us 6-8 animation frames in a 350ms animation. I'll either have something that can do this by M3 or I'll revert back to the old animations.
Where is the code living for the new presentation?
FWIW it is slow for me every time, not just the first time. I used to work on PC video games, and I know that reading from 2D video RAM is notoriously horribly slow. Now, if each view were rendered as a texture on a 3D polygon or something like that, you could do some neat effects with no loss of speed at all. That's essentially how Xgl and Quartz Extreme (see http://en.wikipedia.org/wiki/Xgl) and Looking Glass (https://lg3d.dev.java.net/) work. However the examples I've seen so far have all been done by the OS on the entire application canvas (top level window), mostly without the application knowing about it, as opposed to within views/subwindows of the application and under application control. Pardon the brainstorming, but I wonder how a presentation where every view and editor was a top level window would look. We have an internal MFC application (a debugger) that works that way, but it doesn't have nearly as many windows as Eclipse has. I didn't write the UI but it does some coordination between the windows to help keep them aligned (for example if you resize the bottom of the main window then the bottom of the window next to it will resize also, or if you iconify the main window all of the windows iconify and leave one item in the Windows task bar).
Committed in >20061003. Reverted the animations back to the original style until I can iron out the performance issues. I haven't given up though...;-).
We're reverted back to the old animation style and the new code maintains the correct lazy loading behaviour...
I suspect the screen capture would have broken on Vista anyway given the recent problems with Java there with DirectX and screen locking.
