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, Mo
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 functionali
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 setPul
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
(
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 befo
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);
PaintCollector.getI
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 tha
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
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
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
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 11
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, the
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 c
14 matches
Mail list logo
