For a Node to have a peer to dispose, it must have been attached to a live Scene, right, which must be done on the app thread. Requiring nodes to be removed from a live Stage/Scene on the app thread doesn't seem like a big deal.
To snapshot you could just throw an exception if someone tries to snapshot a node that isn't a part of a live scene. Also no big deal. Then if a Scene's peer is only constructed when it's attached to a live Stage, there's nothing to do there. So it seems like it shouldn't be too hard? On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek <martin.slade...@oracle.com > wrote: > The patch tries to solve the issue by deferring the construction of Scene > in PopupWindow, but the issues I ran into just show that it's not enough. > In order to fix RT-17716, we need Scene construction outside of the thread. > > Looking at the Scene code, it seems that there are not that many places > where app thread is necessary. The Scene's peer is created only when added > to a Window (which is good), but there are still calls that need to be > synchronized or transferred to the app thread. Like when a Node is removed > from a Scene, it's peer is immediately disposed. And also snapshots require > peers (i.e. Scene in a Window), but I guess we can live with that. > I'm also not sure about accessibility, maybe the code would need some > adjustments as well. > > -Martin > > > On 04/28/2014 08:18 PM, Kevin Rushforth wrote: > >> Some of this was looked at while trying to solve RT-17716 < >> https://javafx-jira.kenai.com/browse/RT-17716> (see Martin's patch). >> >> I think it would be worth considering relaxing the restriction on >> constructing Scene and Window (maybe Stage, but I don't think there is a >> benefit for that one), but it seems that Martin ran into some issues with >> his specific patch. >> >> -- Kevin >> >> >> Richard Bair wrote: >> >>> Hi, >>> >>> Actually I don’t know of any reason why Window and Scene cannot be >>> created and initialized on any thread. Each of these has a peer, and the >>> *peer* we can’t update except on the right thread (or with care, these are >>> OS specific restrictions or issues). But I don’t see any reason why the >>> Java side cannot be initialized on any background thread. And in fact, that >>> was always my intent for exactly these reasons, having experienced all this >>> pain in Swing before firsthand. >>> >>> Its just work that needs to be done, contributions welcome :-) >>> >>> Richard >>> >>> On Apr 26, 2014, at 12:48 PM, Tony Anecito <adanec...@yahoo.com> wrote: >>> >>> Hi Tom this is also true for Swing and the EDT. I had heard years ago >>>> jre 8 was going to address this via 2 drawing threads and modularity but >>>> jigsaw was delayed and not sure what happened to the 2 drawing thread idea. >>>> I really wish we could instantiate windows in memory and when needed draw >>>> them. The user experience and perception of java would be so much better >>>> for the client side. If someone on the java client side knows how to do >>>> this I would love to try it to verify it. >>>> >>>> Best Regards, >>>> Tony Anecito >>>> On Saturday, April 26, 2014 11:39 AM, Mike Hearn <m...@plan99.net> >>>> wrote: >>>> >>>> At e(fx)clipse we have an FXML to Java translator who removes all the >>>>> reflection overhead from FXML. It does not yet support all FXML >>>>> features >>>>> but we are steadily improving it and with test cases we are able to fix >>>>> problems quite fast. Maybe this is an option for you? >>>>> >>>>> That would be very interesting to try, yes please! Where can I find >>>> it? My >>>> project is Java 8 based so that's no problem. >>>> >>> >>> >
