Re: [9] API review request: 8090585: Provide an official API to start the JavaFX platform
Wow, this patch will simplify the architecture of JavaFX testing
libraries/frameworks.
>From my perspective it is important to have a method to start the FX
runtime and thread.
I guess one would just use `new Stage()` to create the primary Stage? Or do
we need to register the primary Stage somewhere?
This is a great.
As a sidenote: Another use-case for testing is to be able to call the
Application launch procedure multiple times (probably for different
Application classes) without starting the FX runtime. TestFX currently uses
custom code similar to the code in `LauncherImpl` to archive this.
--Benjamin
On Sun, Nov 22, 2015 at 9:26 PM, Ali Ebrahimi
wrote:
> Hi,
> I know concerns here, but I think PlatformImpl.startup() and
> Platform.startup() should have same behavior from caller's POW.
> So I think if we can not have default behavior(duplicate calls) for public
> API so please change method name.
> My suggestions: Platform.safeStartup() or Platform.startPlatform or
> Platform.start
>
> On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles <
> jonathan.gi...@oracle.com>
> wrote:
>
> > I don't believe there is any inconsistency here. We are preserving the
> > existing semantics in PlatformImpl.startup to not prevent duplicate calls
> > by default, whilst we are reversing the semantics for the public API in
> > Platform, where we do prevent duplicate calls. The end result is that we
> > have one public API (Platform.startup) with one set of semantics (prevent
> > duplicate values).
> >
> > -- Jonathan
> >
> >
> > On 21/11/15 11:57 PM, Ali Ebrahimi wrote:
> >
> > Hi,
> > I think there is an inconsistency between :
> >
> > PlatformImpl.java
> >
> > public static void startup(final Runnable r) {
> > +startup(r, false); //* here default value false
> >
> > + }
> >
> > and
> >
> > Platform.java
> >
> > +public static void startup(Runnable runnable) {
> > +PlatformImpl.startup(runnable, true); // here default
> value true
> >
> > +}
> >
> >
> >
> > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth <
> > kevin.rushfo...@oracle.com> wrote:
> >
> >> Jonathan and all,
> >>
> >> Please review the following new API proposal to add the ability to
> >> explicitly start the FX runtime.
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8090585
> >> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/
> >>
> >> -- Kevin
> >>
> >>
> >
> >
> > --
> >
> > Best Regards,
> > Ali Ebrahimi
> >
> >
> >
>
>
> --
>
> Best Regards,
> Ali Ebrahimi
>
Re: [9] API review request: 8090585: Provide an official API to start the JavaFX platform
Hi,
I know concerns here, but I think PlatformImpl.startup() and
Platform.startup() should have same behavior from caller's POW.
So I think if we can not have default behavior(duplicate calls) for public
API so please change method name.
My suggestions: Platform.safeStartup() or Platform.startPlatform or
Platform.start
On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles
wrote:
> I don't believe there is any inconsistency here. We are preserving the
> existing semantics in PlatformImpl.startup to not prevent duplicate calls
> by default, whilst we are reversing the semantics for the public API in
> Platform, where we do prevent duplicate calls. The end result is that we
> have one public API (Platform.startup) with one set of semantics (prevent
> duplicate values).
>
> -- Jonathan
>
>
> On 21/11/15 11:57 PM, Ali Ebrahimi wrote:
>
> Hi,
> I think there is an inconsistency between :
>
> PlatformImpl.java
>
> public static void startup(final Runnable r) {
> +startup(r, false); //* here default value false
>
> + }
>
> and
>
> Platform.java
>
> +public static void startup(Runnable runnable) {
> +PlatformImpl.startup(runnable, true); // here default value
> true
>
> +}
>
>
>
> On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Jonathan and all,
>>
>> Please review the following new API proposal to add the ability to
>> explicitly start the FX runtime.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8090585
>> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/
>>
>> -- Kevin
>>
>>
>
>
> --
>
> Best Regards,
> Ali Ebrahimi
>
>
>
--
Best Regards,
Ali Ebrahimi
Re: [9] API review request: 8090585: Provide an official API to start the JavaFX platform
I don't believe there is any inconsistency here. We are preserving the
existing semantics in PlatformImpl.startup to not prevent duplicate
calls by default, whilst we are reversing the semantics for the public
API in Platform, where we do prevent duplicate calls. The end result is
that we have one public API (Platform.startup) with one set of semantics
(prevent duplicate values).
-- Jonathan
On 21/11/15 11:57 PM, Ali Ebrahimi wrote:
Hi,
I think there is an inconsistency between :
PlatformImpl.java
public static void startup(final Runnable r) {
+startup(r, false); //* here default value false
+ }
and
Platform.java
+public static void startup(Runnable runnable) {
+PlatformImpl.startup(runnable, true); // heredefault value
true
+}
On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Jonathan and all,
Please review the following new API proposal to add the ability to
explicitly start the FX runtime.
https://bugs.openjdk.java.net/browse/JDK-8090585
http://cr.openjdk.java.net/~kcr/8090585/webrev.00/
Re: Pausing Quantum Renderer
I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, and
the diff is here:
https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc
I am more than happy to create an issue in the openjdk bug system
(enhancement?) and provide a patch there as well, but I think it needs a
bit more discussion first?
- Johan
On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos wrote:
> I have a working implementation that needs more stress-testing on
> different platforms, but it seems a good and easy solution so far.
> I have this on QuantumToolkit:
>
> @Override
> public void pauseRenderer(){
> Application.invokeAndWait(() -> this.pause = true);
> PaintCollector.getInstance().waitForRenderingToComplete();
> };
>
> public void resumeRenderer(){
> Application.invokeAndWait(() -> this.pause = false);
> };
>
> pause is a boolean that is checked for in
> void pulse(boolean collect) { ... }
>
> The difficulty I mentioned in my previous mail (how do we know there are
> no renderJobs pending/running) was solved easily as there exists this
> PaintCollector.waitForRenderingToComplete method.
> This might make the pauseRenderer a bit slower, and maybe this is not
> needed in all usecases. In that case, we can remove it from the
> pauseRenderer() and we can add it either in the Monocle implementation that
> will call pauseRenderer, or in a Android/iOS specific code.
>
> However, it seems to me that if you want to pause the renderer, you most
> often want to make sure no one is still writing to the glSurface after the
> pauseRenderer method is called, so I think it makes sense to keep it there?
>
> - Johan
>
>
>
>
>
>
> On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote:
>
>> I didn't plan to intercept or cancel pending/submitted jobs, but I have
>> to wait until they are done before the android callback method returns.
>>
>> When Android is about to destroy the context, it will call the
>> surfaceTextureDestroyed method on the Activity (the FXActivity in our
>> case). As long as that method doesn't return, the context won't be
>> destroyed. But once that method returns, the context might become invalid
>> any moment. So if there are still jobs that want to do a swapBuffer after
>> we return, those can crash or (even worse) corrupt the egl system.
>>
>> So it seems to me inside the implementation of surfaceTextureDestroyed,
>> we need to achieve 2 things:
>> 1. make sure no new pulses are generated.
>> 2. don't return while the QuantumRenderer is still executing jobs.
>>
>> Those 2 things can be combined in a single Toolkit.pauseRenderer() but it
>> might be better to only achieve the first task in Toolkit.pauseRenderer().
>> The contract for this method is than that no new pulses will be
>> generated, but existing renderJobs might still be running when this method
>> returns.
>> The second thing, waiting for the renderJobs to be finished, can be done
>> in the Android specific implementation.
>>
>> - Johan
>>
>>
>>
>> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> This might be a tricky semantic to achieve, and great care will be
>>> needed to ensure no deadlocks or race conditions. Not running any more
>>> pulses after this method returns seems fine, but it might be better to let
>>> any existing renderJobs run (possibly discarding the results). This way you
>>> could send the pause message to the renderer as a special renderJob and not
>>> have to worry about jobs that are scheduled but not yet run.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Johan Vos wrote:
>>>
After some experiments, here is my current thinking:
Toolkit can have 2 new methods:
pauseRenderer()
resumeRenderer()
When pauseRenderer is called, it should be guaranteed that after this
call,
no new pulses are fired until resumeRenderer is called.
That is not hard, but it is not enough. Before we pause the pulses, the
previous pulse probably submitted a renderJob to Prism, executed on the
QuantumRenderer ThreadPoolExecutor. That job should run fine, as the
next
pulse (when we're back) will call
GlassScene.waitForRenderingToComplete().
So we have to wait until there are no running or pending tasks in the
QuantumRenderer as well.
- Johan
On Wed, Nov 18, 2015 at 9:58 PM, David Hill
wrote:
> On 11/18/15, 3:45 PM, Johan Vos wrote:
>
> Johan,
> I think that it would be reasonable to put in something to Quantum
> that causes the render loop to "pause", and then resume later. I
> envision
> this toggle as causing the render loop to skip, rather than tinkering
> with
> the pulses.
>
> When resume is called, it might be best to treat the world as dirty.
>
> Added to Toolkit, this would allow someone like Monocle to make the
> toggles as is appropriate.
>
> I
RE: JavaFX dependency injection
I think this issue identifies a problem caused by a deeper level of the Java stack: When will CDI become part of Java SE? -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Nitin Malik Sent: Samstag, 21. November 2015 23:00 To: openjfx-dev@openjdk.java.net Subject: JavaFX dependency injection This was asked recently ( http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html) but I didnt see this addressed. Are there plans to have better integration with DI frameworks for views and controllers? For example, we have scenarios where multiple instances of the same view and controllers need to instantiated with different values. This is a frequent question that pops up on Stackoverflow and there apparently is no standard answer. It would help if suggested recipes and guidelines are made available. The solutions we have adopted - 1. Use a controller factory to lookup Spring bean (this isnt ideal because the factory needs to be aware of the bean name). 1a. For singleton controllers, the lookup can be done via class name. 2. Use a controller factory that holds a reference to a controller that was constructed in code with the various parameters. 3. An Afterburner-like framework that scans controller for an annotation and injects the values. Regards, Nitin
