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.
Steps to reproduce: - Run NetBeans with JavaFX Script plugin - Create a JavaFX Script project - Copy the attached FXZ to the project - Right click on the project and select open The IDE is blocked for 12 seconds Alexandr Scherbatiy added a comment - Mar, 10 2009 02:07 PM See NetBeans issue: 159790 Opening big FXZ file blocks IDE http://www.netbeans.org/issues/show_bug.cgi?id=159790 Simon Vienot added a comment - Apr, 7 2009 01:58 PM It seems this issue is in fact related to the FX support in NetBeans. Please report this issue at: http://www.netbeans.org/issues/enter_bug.cgi using the javafx category. Thanks, -Simon Martin Brehovsky added a comment - Apr, 7 2009 06:58 PM Pavle, you should use the new asynchronous load functionality for this. Pavel Benes added a comment - May, 19 2009 08:26 AM Current solution parses the document when requested by FXDLoader. This is done in EDT thread. The background loading cannot be used here since the content does not come from the zip file, but rather from the NB document. The solution is to parse the document before the load itself (in separate) is started and cache the result so that it can be immediately given to the no loader and impact on EDT is as small as possible. The attached files contain most of the solution. Since large impact and possible regression we are not going to do it in Marina release. Pavel Benes added a comment - Oct, 7 2009 02:49 PM New version of FXDPreview supports load on background feature that tries to load FXD document in a smaller chunks and peridiodically yields the EDT, so the UI should not be frozen any more. Lukas Hasik added a comment - Oct, 8 2009 03:32 PM Pavle, then you can close the issue, right?
Created attachment 89185 [details] large fxz
FXDComposer must be also changed to use this new feature. The function com.sun.javafx.tools.fxd.PreviewLoader.loadOnBackground(...) must be used instead of the load(...) function.
planned after 6.8. javafx sdk 1.3 is required
*** Issue 172683 has been marked as a duplicate of this issue. ***
Created attachment 90778 [details] nps snapshot
as this bug is either caused by the fx compiler or it too complicated to fix it in 6.8 - > approved
I just added a snapshot to this coming from using the Bugzilla integration. I do not even have FX integration installed. So the snapshot classifier is not working on this issue. Someone needs to go through the snapshots manually and see what they actually contain.
com.sun.javafx.tools.fxd.PreviewLoader.loadOnBackground(...) is now used instead of load(...). related RT-6580 was also filed and is already fixed (http://javafx-jira.kenai.com/browse/RT-6580). Now waiting for it to be integrated into soma master.
loadOnBackground(...) has reduced fxd loading impact on NB UI performance, but haven't solved the problem completely. It is caused by speciality of rendering fxd in NB. In external viewer fxd is parsed and fxd elements tree is created out of EDT and only rendering is performed in EDT. In NB we have to inject ids into fxd elements (to have selection, navigation etc). Therefore we do not use fxd elements created by fxd DocumentParser, but create our own by wrapping DocumentElements. In current implementation each fxd element or attribute is created lazily when necessary. Which means they are created in EDT. This causes performance problems. Prototype that precreates fxd elements out of EDT before rendering ( but still by wrappig DocumentElements), can't work with medium size fxd because of memory limitation. Current way also needs a lot of time - example SmallWorld.fxz loading takes 10 minutes instead of 17 seconds. It means that we need another way to build fxd elements with injected ids.
Created attachment 93294 [details] SmallWorld.fxz
The wrappers are not there just to inject ids. Another purpose is the ability to load FXD content directly from NB document model, without need to serialize the the content as a file after every edit change. FXDLoader could be updated to be able to run in a "tool mode" where unique id is generated for every element. For example every id can be prefixed by text "<elem-position>_" where elem-position is index of first character in element declaration. This way all javafx.scene.Node inheritors will be available via some unique ID, however it wont solve the other issue. One possibility could be use normal fxd loader (with id injection) to initial document load and than some keep the models in sync so that after each change the whole document is not parsed again. It is definitely not an easy way, but in long term it could provide a good performance.
performans was improved. e.g. huge SmallWorld.fxz loading time is reduced from 10 minutes to 30 sec. For not extremely large fxd, loading time is similar to fx viewer. Small problem with short ui freeze while rendering image still remains. But with current fx version image can't be rendered outside of EDT. The only solution for now is to reduce rendering time by preparing all FXDElements before rendering). But this approach increases total image loading time in 1,5-2 times (depending on fxd structure. Tested on prototype). It doesn't seem to be reasonable for me now. Note for the future. Suggestions from Pavel Benes: 1) Do not allow editing of large FXD/FXZ files and use Viewer like approach to show the large files whereas the smaller one would handled in a same way as now. 2) Use Viewer to show some content quickly without depending on the DocumentElement structure at all. This structure will be created on background and the editing features will be possible when the DocumentElement tree is ready.
The rendering issue is described in the issue 189153