Why can Scene's only be constructed on the UI thread?
Kevin Rushforth
kevin.rushforth at oracle.com
Tue Apr 29 15:56:00 UTC 2014
The snapshot methods already do a thread check and throw an exception if
they are called on a thread other than an app thread.
-- Kevin
Mike Hearn wrote:
> 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.
>>>>>
>>>>>
>>>>
More information about the openjfx-dev
mailing list