Why can Scene's only be constructed on the UI thread?

[Mike Hearn]

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.sladecek at 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 <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>
>>>> 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.
>>>>
>>>
>>>
>