Why can Scene's only be constructed on the UI thread?
martin.sladecek at oracle.com
Tue Apr 29 06:39:01 UTC 2014
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
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.
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:
>> 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 :-)
>> On Apr 26, 2014, at 12:48 PM, Tony Anecito <adanecito at 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 <mike at plan99.net>
>>>> 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
>>>> but we are steadily improving it and with test cases we are able to
>>>> 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.
More information about the openjfx-dev