Bug 156445 - Shell initialization too slow
Summary: Shell initialization too slow
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Silenio Quarti CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-06 17:57 EDT by Eric Moffatt CLA
Modified: 2007-07-29 09:20 EDT (History)
1 user (show)

See Also:


Attachments
SWT Snippet showing a startup issue (3.34 KB, text/plain)
2006-09-06 18:05 EDT, Eric Moffatt CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Moffatt CLA 2006-09-06 17:57:53 EDT
I have a piece of code that my initial timing tests show as taking over 1.5 seconds on a Mac (OK an admittedly old, slooow mac but 1,500 msec?). The code creates a shell and copies the parent shell's bits into a new image (sort of a poor man's double buffer). It seems to be the 'copyArea' that's taking the time...

Snippet coming...

Note: I haven't tried this snippet on the offending machine yet but it's a copy of the code that was giving problems. I'll give it a go tomorrow.
Comment 1 Eric Moffatt CLA 2006-09-06 18:05:17 EDT
Created attachment 49560 [details]
SWT Snippet showing a startup issue


Warning: You have to hit the 'ESC' to close the window (there's a 'no trim' shell overlapping the original shell)...
Comment 2 Silenio Quarti CLA 2006-09-29 11:14:48 EDT
Here is the times to run on my Mac dual 1.25 Ghz G4 PowerPC.

Start: 
  Shell Create: 16
  Image Create: 9
     GC Create: 1
     Copy Area: 974
       Dispose: 0
   Set Visible: 40
        Update: 0
Done: 1040
Comment 3 Silenio Quarti CLA 2006-09-29 12:10:08 EDT
Fixed > 20060929

Please try the latest. The time went down to about 200ms on my machine and Felipe's intel mac.
Comment 4 Eric Moffatt CLA 2006-09-29 15:51:46 EDT
Thanks Selenio, I'll give it a try...

I'm presuming the times you listed were -before- the fix; what are the new times??
Comment 5 Silenio Quarti CLA 2006-10-02 10:33:29 EDT
The fix only affects the "copyArea" time and it is about 200ms (instead of 974) on my machine now.
Comment 6 Eric Moffatt CLA 2006-10-02 11:35:57 EDT
Is this a Mac-only fix or might it help other platforms as well?
Comment 7 Silenio Quarti CLA 2006-10-03 09:48:32 EDT
Mac only. I have not looked at the other platforms. Do you see any performance problems in any other platform?
Comment 8 Eric Moffatt CLA 2006-10-03 13:28:07 EDT
Short answer...yes...;-(. I'm at the point where I think I'll have to re-evaluate my approach. Kim says that even with your patch her performance is still too slow and Boris has similar problems on his XP box. 

Oh well, it was a good try and I'll come back to it later...thanks for your help (and I might come back later if I come up with another approach. BTW, I'm still surprised that we can't get the bits faster on a Mac; based on my almost complete lack of knowledge I'd thought that Mac's already maintained a backing store for a control and I expected getting a control's (shell's?) bits would be very inexpensive. Is there another (perhaps Mac-specific) API that I could use?
Comment 9 Silenio Quarti CLA 2006-10-04 10:02:13 EDT
Getting the bits from the shell on Mac should be faster. Note that this testcase is getting bits from the screen.
Comment 10 Eric Moffatt CLA 2006-10-04 11:15:06 EDT
How would I change the snippet to get the bits from the shell (other than going through its 'display'?
Comment 11 Silenio Quarti CLA 2006-10-05 10:22:16 EDT
Just create the GC on the Shell instead. Note that you will not be able to copy bits from the trim like that.
Comment 12 Eclipse Webmaster CLA 2007-07-29 09:20:53 EDT
Changing OS from Mac OS to Mac OS X as per bug 185991