Community
Participate
Working Groups
Build Identifier: 20120606-2254 I use Ctrl-M to toggle in and out of maximized editor mode a lot. In Eclipse 4.2 RC3 (possibly earlier, not sure -- I recently switched from 3.7.2 to 4.2) this has become extremely slow - it takes about two seconds, and there is absolutely no feedback that anything happened until it suddenly does a quick animation into the new state. Toggling in both directions have the same delay. I attached jvisualvm to see what's going on, and it appears to be related to the fading animation. I'll attach the snapshot. I'm guessing this delay would have something to do with which views are visible, but in the snapshot I'll attach, I only had the views Package Explorer, a single Java editor, the Outline view and the Problems View visible, so I don't think it's a matter of a rogue view taking forever to paint its contents as it's animating or something. P.S. Preferences > General > Appearance has an "Enable Animations" checkbox; turning that off works and makes view switching fast again. But I'm thinking there's something abnormal going on here; animation shouldn't take multiple seconds of precompute/setup time. Reproducible: Always Steps to Reproduce: 1. Open a Java editor 2. Hit Ctrl-M. 3. Wait two seconds, and the editor appears maximized. Should be much faster.
Created attachment 217306 [details] Screenshot of jvisualvm CPU hotspot during toggleZoom delay
Huh, I see this too with RC4 when my system is under load. When it's quiet, then it behaves fine.
You can workaround this bug by going to Preferences - General - Appearance and uncheck the option 'Enable animations'
Yes, this is a known issue in that some systems / platforms take waaay to long to 'scrape' the current screen pixels in order to perform the fade. I'm still trying to find a way that I can default the animations preference based on the particular system being used... Perhaps the best fix for now is to default it as 'off' <sigh, reality always seems to interfere with 'cool'>.
BTW, what system are you on ? :-)
I'm on MacBook Pro, running OSX 10.6.8.
I'm also on Macbook 10.6.8
Thanks, I'm pretty sure that we have one of those around here...I'll check. This is a shame...it really does look good on some systems. Blows my mind really that a system capable of 80 FPS of WoW can't do a fade animation :-( but as I say it's reliant on the ability for me to be able to 'copyArea' *from* the screen.
Agreed. Can you make the default on/off depend on the system type? It's strange that a copy area would be so slow. Maybe it's security related? I know that on the Mac opening files from the terminal (open foo.pdf) takes *forever* the first time after they're downloaded; I'm assuming there's some sort of security validation happening. Wild speculation: Perhaps something similar for security or anti piracy is kicking in here? Or perhaps the library used to copy pixels is slow. In our own plugin, I discovered that drawImage with a scale can be *extremely* slow on some Linux systems (seems tied to the "Cairo" library), so to deal with that, on Linux we always pre-scale everything once and then paint the pre-scaled image in the paint loop.
tor, it's most likely a hold-over from the old CRT days when the bottleneck for resolution and refresh rate was how quickly the screen buffer could be scanned out to the screen. This meant that the only time that the screen memory was available for READ ops was during the vertical refresh (when the electron gun was moving back up to the top of the screen for the next frame). Why it still exists on modern devices is a mystery since LCD screens are effectively 'static'. Even less understandable is why compositing window managers like Win 7 and Macs (I thought...). Here all the bits for each window are buffered in system memory so should be available at backplane rates... We are looking at whether we can 'test' the performance of 'copyArea' once and set the value accordingly but still haven't found a consistently 'correct' formula.
FWIW, the zoom looks terrible on new Retina-display Macs using pixel-doubling as the scraped image is in the native resolution such that the contents appear huge.
Brian, thanks for the update. Looks like I should give it up <sigh>. Does *anybody* use this without problems ?
(In reply to comment #12) > Brian, thanks for the update. Looks like I should give it up <sigh>. > > Does *anybody* use this without problems ? On Ubuntu 11.10/Gnome the whole window goes black for the animation duration if I runn the workbench on a "secondary" screen (Ubuntu seems to really favour leftmost screens). Is a plan to disable animation by default or to remove this option altogether?
I'm marking this as a DUP of bug 357939 since that's where I've put the commit... *** This bug has been marked as a duplicate of bug 357939 ***
