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.
I tried running build 200311251900, with the new windowing system, on OSX. It all seems to work ok, except as soon as I open a file to be edited in the source editor the CPU seems to spin at 100%. This renders the machine pretty much unusably slow - for instance typing in the editor is lagged by several seconds and scrolling is pretty much impossible. The same effect happens if you open the XML editor or the java editor.
the probem seems to be caused by the editor contantly re-drawing as far as i can tell. I can't actully see it re-draing (there's no flickering or anything), but a quick system profile showed that it was spending all it's time in window update code.
I cannot reproduce it on win 2000. Could you please attach a thread dump taken during mentioned behaviour if possible. Thanks.
is there any way to get a stack trace from the binary version (a hotkey or something) or will I have to build it myself and run it in a debugger ? I apologise for my ignorance....
Joshua, You don't need special version of Netbeans to get thread dump. Just press crtl-\ in Terminal window.
I cannot reproduce it on todays build. I am using 10.3.1 and 1.4.2 DP1.
Created attachment 12399 [details] stack traces taken with document editor open (CPU at 100%)
just added a text file with two stack traces taken with an editor window open - cpu therefore running at 100% redrawing the window (thanks Thomas for the little tutorial). One possible clue is that the last thing that appears in the terminal as Netbeans starts up appears to be a warning message from the Apple AWT stuff : "Java couldn't paint in Java_apple_awt_CRenderer_doRect, no focused view" Not sure if this is the problem or not - the CPU usage problem happens whether or not the editor pane is in focus, as long as it's visible I get the problem. This problem seems to happen with any document editor (source editor, xml editor etc.). I suspect it's something to do with how the document editor space is being layed out which is causing constant redrawing, rather than the editor itself.
I can reproduce it on 10.3.0 with JDK 1.4.1, so it seems to me as bug in JDK and it is already fixed in JDK 1.4.2 DP1. Do you have access to JDK 1.4.2 DP1?
Joshua, do you think that we should investigate this issue?
well, if it doesn't happen in the Apple Java 1.4.2 implementation, I guess that it will sort itself out when they release that. On the other hand it means that, in effect, Netbeans 3.6 and above will not be usable on OSX running any version before 1.4.2 - this is likely to be a problem for a lot of people. Also, I haven't experienced anything like this problem with any other Swing application, which makes me suspicious that it isn't exactly a bug in the JDK but just "different behaviour than the windows version". For instance, it's possible that a method is returning immediately on OSX and working asynchronously, whereas Netbeans is expecting it to block. If it is something like that and it doesn't violate the specification then it isn't strictly a bug and Apple probably wouldn't fix it. Speaking personally I would love someone to have a look at this, because I'd like to be using the 3.6 builds, but installing the Apple 1.4.2 beta seed (since it can't be uninstalled) is not really possible for me. OSX doesn't seem a high priority there, though, I get the feeling.....
I expect that 1.4.2 will be released before NetBeans 3.6. Mac OS X is not high priority, but I am doing my best, to support it. I will spend some time to investigate it.
The problem seems to be fixed on my machine. It's either the 10.3.2 system update (released toady) or the Java Advanced Imaging update (also went public today - though i don't think this is the one because I've had the seed installed for a while and it didn't fix the problem). Or perhaps it's the latest Netbeans build ? I downloaded todaays build.
It is the latest NetBeans build. It works fine on 10.3.0 with JDK 1.4.1. This is the same configuration I was able to reproduce it on Dec 5.
Some background info, in case someone needs to solve a similar problem in the future: FWIW, re issue 38650, it appears that this problem is caused by calling Component.getGraphics() from inside Component.paint() - this seems to be a bug in Apple's AWT implementation that doing that resets some state for the Graphics object and triggers a new paint. But having a real need to call Component.getGraphics() is pretty rare, so it should almost always be possible to eliminate such calls.
Mentioned bug in Apple's AWT implementation is fixed in JDK 1.4.2
Tomasi could you please verify it ? I doesn't have the same version of OSX on MAC. Thanks
Verified.