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

Reply via email to