HEADS-UP: switching to gradle 2.9 for FX 9 builds

Testing with gradle 2.9 looks good, so: 's/2.8/2.9/' As a heads-up, we will be switching FX 9 production builds to use gradle 2.9 for building in the very near future. See: https://bugs.openjdk.java.net/browse/JDK-8090171 We will "flip the switch" to make 2.9 the default for building the FX

[9-jake] review request: 8090171: Switch production build of FX to gradle 2.9

David, Please review the simple change to the version check logic to use 2.9 as the preferred version of gradle (with 1.8 still being the default). https://bugs.openjdk.java.net/browse/JDK-8090171 http://cr.openjdk.java.net/~kcr/8090171/webrev.00/ NOTE: as stated in my "HEADS-UP" e-mail,

Re: Java 9 Questions

Answers inline - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92) download? Jigsaw builds are built from a separate sandbox forest: JDK: http://hg.openjdk.java.net/jigsaw/jake JavaFX:

Re: Pausing Quantum Renderer

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

Re: Java 9 Questions

On 11/19/2015 11:49 AM, Scott Palmer wrote: I was just looking at the Java 9 EA pages and have a few questions (mostly JavaFX related). - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92)

Re: Pausing Quantum Renderer

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

Re: Stage.Min/MaxWidth/Height don't scale

Okay, I've submitted a bug report to bugs.java.com where it has been assigned Review ID JI-9026706. -- Chris Kevin Rushforth wrote: Hi Chris, Application developers can file bugs here: http://bugs.java.com/ Thanks. -- Kevin

Re: Pausing Quantum Renderer

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

[8u-dev] Review request: 8143314: Runtime not respected with INI-configuration while creating native bundle

Chris, Danno, Please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8143314 http://cr.openjdk.java.net/~dcherepanov/8143314/webrev.0/ Dmitry

Re: [8u-dev] Review request: 8143314: Runtime not respected with INI-configuration while creating native bundle

+1, but then again, I’m not Danno > On Nov 19, 2015, at 6:14 AM, Dmitry Cherepanov > wrote: > > Chris, Danno, > > Please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8143314 > http://cr.openjdk.java.net/~dcherepanov/8143314/webrev.0/ >

Re: Pausing Quantum Renderer

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