This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 169015 - AWT thread is blocked for long time when repainting tab
Summary: AWT thread is blocked for long time when repainting tab
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Embedded Browser (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P2 blocker (vote)
Assignee: Stanislav Aubrecht
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-07-23 10:06 UTC by Michal Mocnak
Modified: 2009-08-07 09:45 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
profiler dump (12.95 KB, application/octet-stream)
2009-07-23 10:07 UTC, Michal Mocnak 		Details
profiler dump (15.52 KB, application/octet-stream)
2009-07-27 14:02 UTC, Michal Mocnak 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Mocnak 2009-07-23 10:06:09 UTC 
Found in trunk #200907230201 ... it is reproducible from build #200907150201

It seems that is mac os x specific problem. Everytime when i set focus on ide or open projects tab for example whole ide freeze for a while. See dump from 
profiler which is attached. There you are able to see that the method setForeColor takes a lot af time.
Comment 1 Michal Mocnak 2009-07-23 10:07:26 UTC 
Created attachment 85110 [details]
profiler dump
Comment 2 Vitezslav Stejskal 2009-07-23 12:24:09 UTC 
I don't really see anything Netbeans specific here. The call ends up in JDK/java runtime and if this is slow on Mac
there is not much we can do about it.
Comment 3 Michal Mocnak 2009-07-23 12:48:30 UTC 
Reopening. Can be reproduced on each mac (leopard 10.5.7, latest java update).
Comment 4 David Strupl 2009-07-23 13:42:44 UTC 
I am not sure but I read the dump as that method
sun.java2d.loops.DrawGlyphListAA.DrawGlyphListAA takes too long and/or is invoked too often.

Really this does not seem to be NB problem. More like JDK on Mac problem. Can you please try one of those usual tricks
like turning off font antialising and similar?
Comment 5 Michal Mocnak 2009-07-23 13:56:27 UTC 
Sorry but this is not reproducible in build #20090714 ... in all later builds it is. Due to this fact it isn't mac java specific problem.
Comment 6 Michal Mocnak 2009-07-27 14:01:46 UTC 
New informations gained. This is happening only when at least on of the tab is slided in. When docked it's ok. I recorded new profiler dump when you are able 
to find new details in awt thread. Reassigning to the windows system for evaluation.
Comment 7 Michal Mocnak 2009-07-27 14:02:47 UTC 
Created attachment 85251 [details]
profiler dump
Comment 8 Stanislav Aubrecht 2009-07-28 10:09:39 UTC 
sliding windows are now heavyweight components because of embedded browser.
that's probably why repaints on mac are slow...
Comment 9 Stanislav Aubrecht 2009-07-29 16:21:03 UTC 
heavyweight sliding windows are reverted (core-main 156ecf0d4431) so there should be no issues with long repaints
however the side-effect is that sliding windows will show beneath embedded browser window. on the other hand, embedded
browser probably won't be supported on mac os x...
Comment 10 Michal Mocnak 2009-08-07 09:45:15 UTC 
Verified in trunk