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.
JDK 1.6.0-ea-b57. Steps to reproduce: 1) Open one whatever document in the editor 2) Close it It's still "there", until something force refresh (opening new file, switching to another app. and back). Not sure how much we want to support GTK - so leaving only P3. But it is very weird.
The attached patch fix it. Anyway it is still a workaround. I played and debugged it a little and there seems to be no performance problems at all. Should I integrate it? (attaching...)
Created attachment 26397 [details] patch
Yes please, do integrate. Your patch is safe, multiple unneeded repaints should be coalesced by Swing RepaintManager impl anyway, so no performance harm IMHO.
Ok, I'll. But be aware that editorAreaComponent.repaint(); will be called everytime the user types into the editor. But as I used it it seems that RM handle it without any problem as you said.
Change of mind - we decided to *not* integrate the fix now, as extra repainting on every keypress is potentially dangerous when double buffering is off or in case of remote X display, so we should better come with safer fix.
Retested with 6.0 daily and could not reproduce it.
I still can with all other topcomponent docked. latest mustang, latest build. According to the importance of GKT support for next release changing TM to Dev.
> lkishalmi: you have to CC yourself to be notified about the issue progress. See my last comment.
I can't reproduce anymore on Ubuntu 7.04 with JDK 1.6. Closing as worksforme. Please reopen with details if you can still reproduce the issue, thank you.