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.
NB build 06110000 XP JDK1.6.0_01 To reproduce 1. create an ee5 project and on page 1 tab, select clone document from the context menu 2. click and drag on the second page tab (just created) to create a split screen at the bottom half of the designer area 3. click on the upper view and drag and drop a button from the palette to it >designer hangs repainting - no workaround except to kill IDE from taskmanager (or CTRL-C if running from console) Three thread dumps attached, none of which were preceded by any exception a) threaddumpcloneidlock - this is the above scenario b) threaddumpcloneidlock2 - first component dropped was a listbox and it appeared to have no problem until the button was dropped c) threaddumpcloneidlock3 - tested the drop of a textfield and it got further I was able to inline edit but eventually had repainting problems as well and had to kill IDE.
Created attachment 43574 [details] threaddump2
Created attachment 43575 [details] threaddump1
Created attachment 43576 [details] threaddump3
Krys, none of the thread dumps indicates a deadlock (in all of them the AWT thread is runnable). What is actually not working and what means "the designer hangs repainting"?
Peter, as you suggested after viewing my designer hanging, sure enough, after switching JDK -> jdk1.5.0_11 it is *not* reproducible. I will upgrade my 1.6.0_01 to the latest available bits to see if problem is still there.
Upgrading to jdk1.6.0_02 ("6u2") still shows the hang. Filed a JDK java2d bug on this and it has been accepted. http://bt2ws.central.sun.com/CrPrint?id=6568969 I'm assuming it will be fixed in an upcoming 1.6 update jdk so we will probably have to apply for a waiver on this for M10.
Added JDK 1.6 keyword.
This issue is caused by the JDK implementation, i.e. bug in the 6.0. There doesn't seem to be programatic workaround of that issue (see the JDK issues). Requesting to wave, since the issue is entirely in the JDK.
Please see the latest comment in the JDK bug report. It suggests this might actually be a NetBeans issue.
Please re-evaluate. According to note in JDK bug there is a problem on our side so the reason for waiving is not legitimate. Comment from JDK bug: Looks like it's not a java2d problem. I've reproduced the bug. But it's not a hang. For some (netbeans related) issues SunGraphics2D.drawRect called with following huge parameters: x=49 y=24 w=2147483627 h=2147483635 (in my case) So, it's just slow handling such a huge rectangle in AA mode.
That seems to be the problem, there shouldn't be such values passed in. Investigating that. Note: On the other hand, passing huge number values shouldn't be a reason for the JDK to hang for many minutes while drawing a rectangle.
Yes, JDK should clip it. Still, trivial workaround exists on our side. Moreover I expect that should the JDK bug get fixed, we'll have strange visual appearance....
The problem of our code is that there shouldn't occur such a huge number. I.e. the error is deeper, the clipping it would be last resort workaround only. I looking into it, and I hope I'll find the correct fix soon. To the JDK issue: I hope it will get fixed independently on this one.
The issue is with the current impl of WebForm#set(get)CssBoxForElement. It maps element:box 1:1, while it should 1:N. This is a regression avoiding usage of the weak hash maps. Looking for a solution.
Fixed. Checking in visualweb/designer/src/org/netbeans/modules/visualweb/designer/WebForm.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/designer/WebForm.java,v <-- WebForm.java new revision: 1.168; previous revision: 1.167 done
Verified the fix with trunk zip build 06211546 with both jdk1.6.0_02 and jdk1.5.0_11. Yay!