On 11/22/15, 6:24 AM, Johan Vos wrote:
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
The reason I have it in the try is because we need the finally block.
In the postPulse() method, setPulseRunning() is called before the pulse()
method will be called.
Hence, if we want a null pulse we still have to call endPulseRunning()
(which is in the finally block) or we will never have
I tend to agree that the current proposed solution seems minimally
intrusive. The only other thought that I have is wondering whether we
could treat it more like the case of a lost surface on Windows. This
seems very similar to that case.
-- Kevin
David Hill wrote:
On 11/23/15, 11:43 AM,
As the original author of the Quantum toolkit and the renderer, this
sort of addition goes against what I had in mind when designing the
PaintCollector and the renderer. As the renderer is built around a
ThreadPoolExecutor, stopping system functionality for an edge case is
putting the cart
On 11/23/15, 11:43 AM, Morris Meyer wrote:
As the original author of the Quantum toolkit and the renderer, this sort of
addition goes against what I had in mind when designing the PaintCollector and
the renderer. As the renderer is built around a ThreadPoolExecutor, stopping
system
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
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);
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
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
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
On 11/18/15, 8:02 PM, Alexander Kouznetsov wrote:
Shouldn't this be an equivalent of minimizing the window?
That just might work too, but may not be fast enough, would need to dig around
in there to see how quickly it sets state so that the window would not be
treated as dirty. If it needs to
Shouldn't this be an equivalent of minimizing the window?
Best regards,
Alexander Kouznetsov
(408) 276-0387
On 18 ноя 2015 12:45, Johan Vos wrote:
Hi,
On Android, a JavaFX Application might transfer control to another app (and
become invisible) and enter the foreground later. In that case,
And, even if it isn't, shouldn't we have a concept of "you can't draw
right now, just go away and we'll tell you when it's available again"
built into the Presentable API? You shouldn't have to set the
dimensions to 0,0 to mean "I'm not here right now"...
...jim
On
13 matches
Mail list logo
