Re: armv6hf build failing with multiple definition of `JNI_OnLoad'

[Chris Newland]

Thanks Kevin,

I'll take a look and post a patch here if I can get it working before the
official fix.

Kind regards,

Chris

On Wed, November 14, 2018 11:20, Kevin Rushforth wrote:
> The main change that went in recently (On Oct 26) that would affect this
> is JDK-8212147 [1], the backport of GTK 3 to FX 8, which was pushed to
> 8u-dev about 3 weeks ago.
>
>
> Similar changes to those made in buildSrc/linux.gradle will likely be
> needed in buildSrc/armv6hf.gradle.
>
> -- Kevin
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212147
>
>
>
> On 11/14/2018 10:48 AM, Chris Newland wrote:
>
>> Hi all,
>>
>>
>> Despite all the cool new build stuff being done with OpenJFX I still
>> get a few queries about my nightly chriswhocodes.com OpenJFX8 builds for
>> ARM
>> from the Pi community.
>>
>> Someone recently noticed that my builds broke on Oct 26 2018.
>>
>>
>> I've posted a gist of the failure log here
>>
>>
>> https://gist.github.com/chriswhocodes/b48a0fa1349d52f6c68be9d4212391d8
>>
>>
>> and was wondering if anyone had any ideas what might have broken this?
>>
>> Reproducible with a fresh clone of
>> http://hg.openjdk.java.net/openjfx/8u-dev/rt and crosslibs fetch.
>>
>>
>> Many thanks,
>>
>>
>> Chris
>>
>>
>
>

armv6hf build failing with multiple definition of `JNI_OnLoad'

[Chris Newland]

Hi all,

Despite all the cool new build stuff being done with OpenJFX I still get a
few queries about my nightly chriswhocodes.com OpenJFX8 builds for ARM
from the Pi community.

Someone recently noticed that my builds broke on Oct 26 2018.

I've posted a gist of the failure log here

https://gist.github.com/chriswhocodes/b48a0fa1349d52f6c68be9d4212391d8

and was wondering if anyone had any ideas what might have broken this?

Reproducible with a fresh clone of
http://hg.openjdk.java.net/openjfx/8u-dev/rt and crosslibs fetch.

Many thanks,

Chris

Re: JavaFX 11 is released

[Chris Newland]

Congratulations to all involved in this!

Looking forward to seeing JavaFX grow now it's outside of the JDK.

-Chris

On Tue, September 18, 2018 14:08, Johan Vos wrote:
> Adding to what Kevin already said (huge thanks to Kevin and Oracle for
> all they did), I want to thank everyone on this list for being part of
> this release. The JavaFX 11 release is a huge milestone, and there are
> many people who contributed, some of them who have been working with
> JavaFX from
> day 1, some who just started working.
>
> As for the site http://openjfx.io: this is something we created with
> Gluon,
> but we really want it to be a community-organised site. Therefore, it is
> all available via github, and open for PR's:
> https://github.com/openjfx/hugo-site.
>
>
> Thanks again,
>
>
> - Johan
>
>
> On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth
> 
> wrote:
>
>
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>>
>> http://openjfx.io/
>>
>>
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>>  at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>>
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>>  which is available as a release candidate now and will be shipped as a
>>  GA version next week, or on JDK 10 (OpenJDK build only).
>>
>>
>> A big thank you to all who have contributed to OpenJFX make this
>> release possible! I especially thank Johan Vos, both for taking on the
>> role as Co-Lead of the OpenJFX Project and for the work that Gluon as
>> done to build and host the JavaFX 11 release.
>>
>> I look forward to working with you all on JavaFX 12 and beyond.
>>
>>
>> -- Kevin
>>
>>
>>
>

Re: More community participation in JavaFX

[Chris Newland]

Hi Kevin,

I'm more than happy to keep the community JavaFX build server at
chriswhocodes.com running and host JDK 8/9/10/n + FX builds there.

At the moment it's mostly used by the Raspberry Pi community to grab
JavaFX overlays for JDK8 on ARM.

I can also build and host OSX and Windows builds there once the build
instructions are updated.

Lastly I'd also be interested in profiling and contributing performance
enhancements to the FX Java source code based on JIT analysis. IMO it
would be useful if the OpenJFX team would make a statement on what kind of
contributions fit with their overall vision (e.g. increasing performance
vs bug fixing desktop widgets).

Thanks,

Chris




On Thu, February 1, 2018 23:26, Kevin Rushforth wrote:

To: OpenJFX Developers

We are looking to grow the community of contributors to the OpenJFX
project, especially serious contributors who will stick around long
enough to become reviewers, to help us keep the platform vibrant. To
this end we are looking at ways to encourage more participation and make
it easier for interested folks to contribute.
...

Re: Building OpenJFX.

[Chris Newland]

Hi Phil,

Would it be possible to update the Windows build instructions? Getting
VS10 and SDKs from 2010 to work on a Windows 10 build machine isn't much
fun.

Thanks,

Chris



On Tue, December 19, 2017 20:11, Phil Race wrote:
> In the "innovation" email thread it was suggested that one obstacle to
> getting involved and contributing to OpenJFX is just building it.
>
> So what are the top one or two pain points with building OpenJFX today ?
>
>
> - Insufficient or out-dated build docs ?
> - Tool-chain configuration problems - platform-specific or otherwise ?
> - Needing to do a JDK build as well (JDK 9 and later) ?
> - Something else ?
>
>
> And having identified your pain point(s), what do you think would be a
> solution ?
>
> -phil.
>
>

Re: Innovation again (was Re: Text classes)

[Chris Newland]

Hi John,

Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the
JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for
fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX).

On the whole I think the API is very good. Event handling, layout, choice
of components give me 99% of what I need.

The CSS approach to styling feels a bit clunky when I want to change
fine-grained appearance programatically without defining new CSS classes.
Proper font metrics would be nice too (already discussed recently).

The Canvas/GraphicsContext API provides a decent entry point into "old
school" 2D programming and a way to avoid the scenegraph which does suffer
with scale when you push it too hard. You can do fun things with
PixelReader/Writer.

Personally I'd like an even lower level API to framebuffers as the current
implementation looks a bit copy-heavy (my opinion from just the source
code, I've not had time to see how much the JIT saves us here). I'd really
like the video frame grabber API for MediaPlayer (deprecated after 8)
added back but I'm probably alone here. I can always go off-heap here or
just implement a video decoder in pure Java.

For 3D I think a component that provides a surface usable by an existing
OpenGL library is probably better than trying to replicate in pure OpenJFX
but this isn't really my area.

I was disappointed when Oracle decided to drop support for ARM / IoT but
that's no reflection on the JavaFX team, just a commercial decision by a
cloud-focused company. I've tried to keep IoT support going via community
builds of JavaFX 8 at https://www.chriswhocodes.com but I never really
cracked getting Windows builds working. I'm hoping to find some time next
year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges
(Marlin/MarlinFX) to improve early access testing and cross-platform
support of OpenJFX builds. This got a lot harder since the modular JDK9
where you can no longer simply modify OpenJFX, rebuild, and drop an
overlay onto your JRE.

There are a few companies doing great work (Canoo, Gluon etc.) and a long
list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio,
Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I
think about it the longer this list gets) who showcase what is possible.

The Gluon mobile stuff looks really interesting and I've just started
trying to rewrite an iOS native app into a cross-platform app using their
Eclipse plugin.

In summary I'm very happy with JavaFX and I think the community, while
small, contains a lot of talent and energy.

The "official" OpenJFX devs are responsive to the community while being
realistic about what can be achieved outside their sanctioned roadmap.

If there's 1 single thing I'd like to ask for it's an updated set of build
instructions for each platform. That's the biggest barrier to getting more
community patches submitted in my opinion.

Just the $0.02 of one JavaFX user ;)

Cheers,

Chris
--
@chriswhocodes



On Wed, December 13, 2017 02:28, John-Val Rose wrote:
> I posted this over a week ago:
>
>
>> I am willing to work with *anyone* (within Oracle or not) on the
>> features
> that the community craves,
>> such as those I listed (and any others). Not just because “many hands
> make light work” but because
>> I don’t know everything (or even close) and I need the knowledge and
>>
> skills of others to assist me. Not
>> to mention that I have only 24 hours in a day like everyone else and,
> also like everyone else, some of
>> that time has to be devoted to earning an income.
>>
>> So, if there’s anyone reading this who has the time, the skills, the
>>
> commitment and the passion to work hard (in your own time) to get these
> tasks done then please contact me privately.
>
> To my significant disappointment, only one person has contacted me since
> then in relation to this proposal.
>
> I'm beginning to think that I am completely out of touch with the JavaFX
> community, what they actually want and also with exactly *what* JavaFX is
> or is meant to be.
>
> I have reached out on this list and via Twitter in the hope that an
> inspired and passionate group of developers could come together, pool
> their resources and collaborate on taking JavaFX as far is it can possibly
> go as a fully-fledged hardware-accelerated graphics toolkit for the JVM.
>
> But... it seem that my "vision" for JavaFX is unique to me and I have to
> say that I really don't understand why that is.
>
> Is it that the JavaFX community see it as merely a Swing replacement or
> "upgrade" and that there just aren't people out there who want to do more
> sophisticated things with a Java-based toolkit or at least see performance
>  increase dramatically?
>
> Or, do people feel that the kind of features you can find in say Qt
> cannot be added to JavaFX because it's a "Java thing": well all know how
> slow Java is and that if you want to do real animations, visualisations
> 

Re: Error on build

[Chris Newland]

Thanks David.

Do you know if the WINSDK and DirectX requirements are still as per the
wiki/docs or can later versions be used?

Cheers,

Chris
@chriswhocodes | JITWatch | DemoFX

On Wed, October 4, 2017 13:15, David Bimamisa wrote:
> It should also work with the community version of VS2017
>
>
> Regards
> David
>
>
>
> Am 03.10.2017 5:56 nachm. schrieb <jav...@use.startmail.com>:
>
>
> VS 2017 Professional is now required to build OpenJFX.
>
>>
> Ahh I see. I am sure it needs every bit of power offered by the
> professional version of Microsoft's excellent dev environment but
> unfortunately it cuts me out of building or testing since I don't have
> that subscription and it's really rather pricey.
>
> Cheers!
>
>
>
>
>
>>
>>
> On Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>
>> The Wiki is out of date. VS 2017 Professional is now required to build
>> OpenJFX. A fix was just pushed [1] to allow a different build of VS 2017
>>  than the hard-coded one.
>>
>> Also, I am still able to build with VS 2010 and VS 2013, which should
>> work as long as you don't build media or webkit (they aren't built by
>> default).
>>
>> -- Kevin
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8187366
>>
>>
>>
>>
>> Chris Newland wrote:
>>
>>
>>>
>>> Hi,
>>>
>>>
>>> I'm also trying to build OpenJFX on Windows 10 so I can add a
>>> Windows
>>> build to my community OpenJFX build server at
>>> https://chriswhocodes.com
>>> and am hitting the same problems as you.
>>>
>>> Setting WINSDK_DIR on the command line using 'set' or 'export'
>>> doesn't work and neither does setting via the Windows environment
>>> manager UI.
>>>
>>>
>>> Hardcoding got me past this one:
>>>
>>>
>>> def WINDOWS_SDK_DIR="..." above the check.
>>>
>>> Next error I'm hitting is NativeCompileTask.compile()
>>>
>>>
>>> This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June
>>> 2010.
>>>
>>>
>>> buildSrc/win.gradle has hardcoded paths to VS2017 Professional so I'm
>>> guessing the devs who wrote this build script have got it working on a
>>> more modern build environment than the one described in the docs.
>>>
>>> Will post here if I can get it to build.
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Chris
>>>
>>>
>>> On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
>>>
>>>
>>>
>>>>
>>>> Hi again !
>>>>
>>>>
>>>>
>>>> Well I was able to track down the source of the error I am
>>>> receiving from the gradle build. Unfortunately, the error persists,
>>>> which is a bit of a mystery. Maybe a gradle maven can enlighten me
>>>> here.
>>>>
>>>> For some reason, this line on line 90-91 of win.gradle is throwing
>>>> the exception, although I can prove it ought not to:  if
>>>> (WINDOWS_SDK_DIR ==
>>>> null || WINDOWS_SDK_DIR == "") { throw new GradleException("FAIL:
>>>> WINSDK_DIR not defined");
>>>> I cannot get past this, the exception is triggered, and yet the
>>>> assignment of a value to property WINDOWS_SDK_DIR is quite clear here
>>>> (line
>>>> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties,
>>>> System.getenv().get("WINSDK_DIR"))
>>>> and that system variable is, in fact, set as proved by (my) running
>>>> this simple program I wrote (which exists in the same directory as
>>>> win.gradle to exclude any conceivable path issues) and getting the
>>>> proper outputpublic class WinSDK { public WinSDK() { } public static
>>>> void main(String[] args) { String sdk =
>>>> (String)System.getenv().get("WINSDK_DIR");
>>>> System.out.println("sdk = " + sdk);
>>>> }
>>>> }
>>>> Output as expected- the proper path to Microsoft SDK and anyways
>>>> certainly not the empty string or null.
>>>>
>>>>
>>>>
>>>> Sorry to ask such a basic question but is anyone on this list
>>>> actually able to clone then compile OpenFX from source using the
>>>> procedure outlined on the

Re: Error on build

[Chris Newland]

Hi,

I'm also trying to build OpenJFX on Windows 10 so I can add a Windows
build to my community OpenJFX build server at https://chriswhocodes.com
and am hitting the same problems as you.

Setting WINSDK_DIR on the command line using 'set' or 'export' doesn't
work and neither does setting via the Windows environment manager UI.

Hardcoding got me past this one:

def WINDOWS_SDK_DIR="..." above the check.

Next error I'm hitting is NativeCompileTask.compile()

This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June 2010.

buildSrc/win.gradle has hardcoded paths to VS2017 Professional so I'm
guessing the devs who wrote this build script have got it working on a
more modern build environment than the one described in the docs.

Will post here if I can get it to build.

Cheers,

Chris

On Tue, October 3, 2017 02:14, jav...@use.startmail.com wrote:
> Hi again !
>
>
> Well I was able to track down the source of the error I am receiving
> from the gradle build. Unfortunately, the error persists, which is a bit of
> a mystery. Maybe a gradle maven can enlighten me here.
>
> For some reason, this line on line 90-91 of win.gradle is throwing the
> exception, although I can prove it ought not to:  
> if (WINDOWS_SDK_DIR == null || WINDOWS_SDK_DIR == "") { throw new
> GradleException("FAIL: WINSDK_DIR not defined");
> I cannot get past this, the exception is triggered, and yet the
> assignment of a value to property WINDOWS_SDK_DIR is quite clear here (line
> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties,
> System.getenv().get("WINSDK_DIR"))
> and that system variable is, in fact, set as proved by (my) running this
> simple program I wrote (which exists in the same directory as win.gradle
> to exclude any conceivable path issues) and getting the proper
> outputpublic class WinSDK { public WinSDK() { }
> public static void main(String[] args) { String sdk =
> (String)System.getenv().get("WINSDK_DIR");
> System.out.println("sdk = " + sdk);
> }
> }
> Output as expected- the proper path to Microsoft SDK and anyways
> certainly not the empty string or null.
>
>
>
> Sorry to ask such a basic question but is anyone on this list actually
> able to clone then compile OpenFX from source using the procedure outlined
> on the below mentioned page using any of the gradle scripts, (in my
> instance gradle.win) ?
>
> Seems like first -step level stuff that is done regularly by everyone
> on the list interested in improving or exploring OpenFX but maybe I am
> wrong about this? 
>
> Many thanks in advance. 
>
>
>
>
>
>  
> On Thursday, September 28, 2017 6:59 PM, jav...@use.startmail.com
> wrote:
>  
>
>> Hi All,
>>
>>
>> New member to this group. I am encountering a little trouble  when I
>> try to build OpenJFX. I am following the instructions here: (using Cygwin
>> on Win 7):
>>
>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>>
>>
>> When I run gradle after cloning the OpenJFX repository, I get a
>> "build
>> failed with exception" . I include the output from the entire run just in
>> case it's significant:
>>
>>
>>
>> $ gradle
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by
>> org.gradle.internal.reflect.JavaMethod
>> (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method
>> java.lang.ClassLoader.getPackages() WARNING: Please consider reporting
>> this to the maintainers of org.gradle.internal.reflect.JavaMethod
>> WARNING: Use --illegal-access=warn to enable warnings of further
>> illegal reflective access operations WARNING: All illegal access
>> operations will be denied in a future release
>> :buildSrc:generateGrammarSource UP-TO-DATE
>> :buildSrc:compileJava UP-TO-DATE
>> :buildSrc:compileGroovy UP-TO-DATE
>> :buildSrc:processResources UP-TO-DATE
>> :buildSrc:classes UP-TO-DATE
>> :buildSrc:jar UP-TO-DATE
>> :buildSrc:assemble UP-TO-DATE
>> :buildSrc:compileTestJava UP-TO-DATE
>> :buildSrc:compileTestGroovy UP-TO-DATE
>> :buildSrc:processTestResources UP-TO-DATE
>> :buildSrc:testClasses UP-TO-DATE
>> :buildSrc:test UP-TO-DATE
>> :buildSrc:check UP-TO-DATE
>> :buildSrc:build UP-TO-DATE
>>
>>
>> FAILURE: Build failed with an exception.
>>
>>
>> * Where:
>> Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line: 91
>>
>>
>> * What went wrong:
>> A problem occurred evaluating script.
>>
>>> FAIL: WINSDK_DIR not defined
>>>
>> * Try:
>> Run with --stacktrace option to get the stack trace. Run with --info
>> or --debug option to get more log output.
>>
>>
>> BUILD FAILED
>>
>>
>> Total time: 1.376 secs
>>
>>
>>
>> I should add that even though the tutorial doesn't mention to do it,
>> I
>> cd-ed into the folder named rt, which was created by Mercurial when I
>> cloned OpenJFX,  I called gradle from there. Calling it from the
>> directory containing rt resulted in nothing happening , which makes
>> sense afaik.
>>
>> the variable WINSDK is  not one I am familiar with- it's not any
>> environment or system variable on 

Re: Review: Remove Lens code (finally)

[Chris Newland]

Thanks for the heads-up David.

I've checked my chriswhocodes.com web server logs and around 90 unique IPs
per week are still downloading the ARM OpenJFX overlay builds so before
this patch is merged I'll take a snapshot of the last working ARM build
and keep that available.

Kind regards,

Chris

On Tue, April 18, 2017 21:47, David Hill wrote:
>

> Here is the change to remove the Lens code.
>
>
> caviots:
> There were some minor gradle fixes required to cross build.
>
>
> I removed all of the arm*gradle files except for armv6hf. Arm is not a
> supported platform anymore and by reducing to the most likely to be used
> (because of the Pi), I can concentrate what few resources I can to
> checking that platform still builds.
>
> Armv6hf builds cleanly. I don't have a working Pi configuration to test
> it, and need to figure out building the JDK for ARM before I really can
> test it even then.
>
> We have not been using Lens for JDK 8,9 so this should be safe.
>
>
> https://bugs.openjdk.java.net/browse/JDK-8090969
> webrev: http://cr.openjdk.java.net/~ddhill/8090969
>
>
> --
> David Hill
> Java Embedded Development
>
>
> "A man's feet should be planted in his country, but his eyes should
> survey the world." -- George Santayana (1863 - 1952)
>
>
>

Re: Is a Desktop Experience on ARM with X11 Possible?

[Chris Newland]

Hi Scott,

I run windowed JavaFX desktop apps on the Raspberry Pi 3 (Latest Raspbian
+ PIXEL desktop without experimental driver) using the GTK platform and
software pipeline with an OpenJFX build from my server at
https://chriswhocodes.com/

Just download an ARM nightly:

wget
https://chriswhocodes.com/downloads/openjfx-8-sdk-overlay-linux-armv6hf.zip

and unzip it over your JDK

unzip openjfx-8-sdk-overlay-linux-armv6hf.zip -d /home/pi/jdk1.8.0_121

and then add the switches -Dprism.platform=gtk -Dprism.order=sw to your
java command.

Cheers,

Chris

On Thu, February 9, 2017 19:08, Scott Palmer wrote:
> Just wondering if there are some options for building OpenJFX for
> embedded ARM such that it behaves like it does on x86 Linux with X11. I
> mean with actual decorated windows instead of just  lumping everything
> onto the frame buffer or a single window.
>
> Is this currently possible?
>
>
>
> Scott
>
>

Re: Planning for JavaFX.next

[Chris Newland]

Hi Jonathan,

+1 to that list for me.

In my experience JavaFX performs well for the "low-level" (Canvas +
GraphicsContext) stuff with one exception - the PixelWriter APIs appear do
a lot of array duplication and copying under the hood which I believe can
be optimised. I'll investigate further and try to come up with a patch.

Nice to have (but lower priority than everything on the list) would be a
public API for grabbing frames from a MediaPlayer which used to be
possible in 8 with player.impl_getLatestFrame().

Echoing Tom and Felix, my #1 priority would be fixing scenegraph
performance as tables with large row counts and charts (e.g. XYChart) with
large numbers of data points (e.g. 50K) in their Series can easily lead to
multi-second render times and huge heap usage.

Thanks for opening this discussion,

Chris

On Wed, December 7, 2016 23:45, Jonathan Giles wrote:
> Hi folks,
>
>
> Development on JDK 9 is slowly starting to ramp down, and we are
> starting to turn our attention to the goals for JavaFX in JDK 10 and
> beyond. We are starting to compile our list of what we think is important,
> but we really want to hear from the community about what their highest
> priorities are to them. As always, it's important to keep in mind what
> JavaFX is (e.g. it isn't aiming to be a high-performance
> game engine), but even still there are bound to be a number of places where
> people might want to weigh in, for example:
>
> * New layout containers (e.g. Flexbox)
> * Public APIs for UI control behaviors
> * Marlin renderer enabled by default
> * Support for CSS animations
> * CSS performance improvements
> * TableView improvements (cell spanning, row / column freezing, etc)
> * TableView performance
> * Focus traversal API
> * WebGL support in WebView
> * Improved image I/O support
> * A JavaFX equivalent of the AWT Desktop APIs
> * Multi-res image API
> * NIO-backed writable images
>
>
> If there are other areas of interest that aren't listed here, please
> start discussing them and we can work together to determine priorities. If
> all you want to do is add a +1 for one of more of the items above, even
> that will be very useful.
>
> Thanks,
> -- Jonathan
>
>

New JavaFX performance benchmark (DemoFX part III)

[Chris Newland]

Hi all,

Hope not too off-topic but I've just released the 3rd version of my JavaFX
performance benchmark "DemoFX".

This time it exercises the PixelWriter (of Canvas and WriteableImage), the
spectral analyser (thanks for adding this!), and some 3D as well as
drawing on the Canvas.

It does use MediaPlayer.impl_getLatestFrame() to grab raw frames for the
chroma-key / green-screen effects so won't be compatible with JDK9 (I did
file RFE JI-9038459 for this but realise it's low priority).

The code is fairly unoptimised (but still runs 60fps on my 2011 iMac) but
I'm going to spend a bit of time looking at what the JIT gets up to and
come back with any suggestions.

Code is here: https://github.com/chriswhocodes/DemoFX and a video here
https://www.youtube.com/watch?v=9jztG_l8qrk

Hopefully a useful showcase for JavaFX realtime graphics.

Cheers,

Chris
@chriswhocodes on Twitter

Re: OSX+Radeon crash VideoDataBuffer.convert YCbCr_422 -> BGRA_PRE

[Chris Newland]

Thanks Kevin, filed RFE with Review ID: JI-9038459.

I've found this was a really powerful way to do things like real-time
chroma keying (green screening) in JavaFX so will keep an OpenJFX snapshot
around to preserve this functionality.

Will be releasing another JavaFX tech demo soon :)

Cheers,

Chris

On Wed, May 25, 2016 13:29, Kevin Rushforth wrote:
> I'm not surprised this causes problems, as it is almost certainly not
> thread-safe.
>
> FWIW, this impl_ method is already inaccessible in JDK 9 because it
> returns a type that is not exported from the javafx.media module. Further,
> this methods will go away very soon as part of the ongoing encapsulation
> of all impl_ methods.
>
> Can you file an RFE for a public API to do this? We can consider it for
> a future version of JavaFX.
>
> -- Kevin
>
>
>
> Chris Newland wrote:
>
>> Hi,
>>
>>
>> This is really just an FYI as I'm doing funky stuff with multiple
>> MediaPlayers and using the deprecated impl_getLatestFrame() method to
>> grab frames.
>>
>> I can grab frames fine with a single MediaPlayer instance but when I
>> use multiple MediaPlayer objects each with an AnimationTimer calling
>> this code:
>>
>>
>> public void snapshotVideo() {
>> VideoDataBuffer buf = player.impl_getLatestFrame();
>>
>>
>> if (buf != null) {
>> VideoFormat newFormat = VideoFormat.BGRA_PRE;
>> buf = buf.convertToFormat(newFormat);
>>
>> ByteBuffer bb =
>> buf.getBufferForPlane(VideoDataBuffer.PACKED_FORMAT_PLANE);
>>
>> int pixel = 0;
>>
>> int max = bb.remaining() / 4;
>>
>> for (int i = 0; i < max; i++) {
>> rawFrameData[pixel++] = bb.getInt(); }
>>
>>
>> buf.releaseFrame(); }
>> }
>>
>>
>> then it crashes hard on OSX El Capitan with AMD Radeon HD 6970M with
>> this dump:
>> https://gist.github.com/chriswhocodes/5516d24078205dc218dead870853e018
>>
>>
>> I'm guessing the native frame conversion from YCbCr_422 to BGRA_PRE is
>> not thread-safe but some naive attempts to lock around this haven't
>> solved the problem.
>>
>> This same code + videos works fine on a MacBook Pro with Intel Iris
>> graphics so it's a tiny hardware+OS corner case but thought it might be
>> worth a mention.
>>
>> The only thing I'd add is that I'd love to have an official API for
>> grabbing single frames from video. I've been doing some cool real-time
>> video effects in JavaFX and it's a shame to have to use a deprecated
>> method which will probably go away.
>>
>> Cheers,
>>
>>
>> Chris
>>
>>
>>
>

OSX+Radeon crash VideoDataBuffer.convert YCbCr_422 -> BGRA_PRE

[Chris Newland]

Hi,

This is really just an FYI as I'm doing funky stuff with multiple
MediaPlayers and using the deprecated impl_getLatestFrame() method to grab
frames.

I can grab frames fine with a single MediaPlayer instance but when I use
multiple MediaPlayer objects each with an AnimationTimer calling this
code:

public void snapshotVideo()
{
VideoDataBuffer buf = player.impl_getLatestFrame();

if (buf != null)
{
VideoFormat newFormat = VideoFormat.BGRA_PRE;
buf = buf.convertToFormat(newFormat);

ByteBuffer bb =
buf.getBufferForPlane(VideoDataBuffer.PACKED_FORMAT_PLANE);

int pixel = 0;

int max = bb.remaining() / 4;

for (int i = 0; i < max; i++)
{
rawFrameData[pixel++] = bb.getInt();
}

buf.releaseFrame();
}
}

then it crashes hard on OSX El Capitan with AMD Radeon HD 6970M with this
dump:
https://gist.github.com/chriswhocodes/5516d24078205dc218dead870853e018

I'm guessing the native frame conversion from YCbCr_422 to BGRA_PRE is not
thread-safe but some naive attempts to lock around this haven't solved the
problem.

This same code + videos works fine on a MacBook Pro with Intel Iris
graphics so it's a tiny hardware+OS corner case but thought it might be
worth a mention.

The only thing I'd add is that I'd love to have an official API for
grabbing single frames from video. I've been doing some cool real-time
video effects in JavaFX and it's a shame to have to use a deprecated
method which will probably go away.

Cheers,

Chris

default X86EGL.includeSwing = true for headless Linux?

[Chris Newland]

Hi,

Currently Monocle builds are configured (in buildSrc/x86egl.gradle) with

X86EGL.includeSwing = false

This results in build.gradle excluding javafx/embed/swing packages

if (!targetProperties.includeSwing) {
exclude("javafx/embed/swing")
}

Which means that you can't easily (to my knowledge) create writeable
images on headless Linux systems using SwingFXUtils:

ImageIO.write(SwingFXUtils.fromFXImage(imag, null), "png", new
File("snapshot.png"));

setting

X86EGL.includeSwing = true

makes the javafx/embed/swing packages available and fixes the problem.

I imagine it's done this way to keep the size down for embedded images?

If there's no intention to change the default then I'm happy to offer a
Swing-enabled monocle build on my OpenJFX build server (which now has a
domain: http://chriswhocodes.com).

Kind regards,

Chris

Re: Huge JavaFX performance drop in Debian Jessie

[Chris Newland]

Hi Kevin,

The JavaFX performance when forcing the sw pipeline is still much slower with 
Jessie than Wheezy so I'm hoping there is something I can do at the OS level to 
get back to previous sw performance.

Will let you know if I find it!

Cheers,

Chris

Sent from my iPhone

> On 22 Dec 2015, at 15:52, Kevin Rushforth  wrote:
> 
> We require Pixel Shader 3 support and this GPU doesn't really have full HW 
> support. Most drivers will attempt to emulate with somewhat mixed results. If 
> this card were in a system running Windows we would automatically detect and 
> fall back to SW. This isn't as easy to do in Linux, but maybe it would be 
> possible (Chien might want to comment on the feasibility of detecting this on 
> Linux).
> 
> -- Kevin
> 
> 
> Markus KARG wrote:
>> Just to understand "not supported GPU" better: Is there GPU-specific code in
>> JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU?
>> 
>> -Markus
>> 
>> -Original Message-
>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
>> Chien Yang
>> Sent: Dienstag, 22. Dezember 2015 09:01
>> To: cnewl...@chrisnewland.com; openjfx-dev@openjdk.java.net
>> Subject: Re: Huge JavaFX performance drop in Debian Jessie
>> 
>> Hi Chris,
>> 
>> JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a
>> high likelihood that the drop in performance is caused by the switch from sw
>> pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA
>> 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing
>> JavaFX to use its sw pipe by specifying -Dprism.order=sw in the run command.
>> 
>> - Chien
>>  

Re: Huge JavaFX performance drop in Debian Jessie

[Chris Newland]

ive Method)
- parking to wait for  <0xe0ffcda8> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:200)
at
com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:143)
at javafx.application.Application.launch(Application.java:252)
at org.adoptopenjdk.jitwatch.ui.JITWatchUI.(JITWatchUI.java:185)
at org.adoptopenjdk.jitwatch.launch.LaunchUI.main(LaunchUI.java:18)

"VM Thread" os_prio=0 tid=0x7fec88073800 nid=0x17d5 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x7fec8801f000
nid=0x17d3 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x7fec88021000
nid=0x17d4 runnable

"VM Periodic Task Thread" os_prio=0 tid=0x7fec880bd000 nid=0x17dc
waiting on condition

JNI global references: 1037







On Tue, December 22, 2015 08:00, Chien Yang wrote:
> Hi Chris,
>
>
> JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There
> is a high likelihood that the drop in performance is caused by the switch
> from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an
> underpowered GPU for JavaFX's es2 pipe. You can try forcing JavaFX to use
> its sw pipe by specifying -Dprism.order=sw in the run command.
>
> - Chien
>
>
> On 12/21/2015 03:02 PM, Chris Newland wrote:
>
>> Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy
>> to Debian Jessie and JavaFX performance has suffered a huge drop :(
>>
>>
>> Possibly not JavaFX related but native apps (firefox etc) all seem to
>> perform the same and glxgears runs full sync framerate and 350fps
>> unsynced.
>>
>> JavaFX stages open blank and can take 5 seconds to render. Trying to
>> scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app
>>  for 10s+.
>>
>> Previously stages opened in under 1s and scrolling was instant.
>>
>>
>> My DemoFX test platform (Canvas based effects) seems to run the same so
>> it only appears to be windows / stages that are affected.
>>
>> It's an old (2010) system but JavaFX performance has dropped from slow
>> to unusable.
>>
>> Will keep investigating and test on my Debian desktop once I upgrade it
>> to Jessie.
>>
>>
>> Cheers,
>>
>>
>> Chris
>> @chriswhocodes
>>
>>
>> JavaFX debug:
>>
>>
>> Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension
>> initializeIfAvailable INFO: Failed to initialize management extension
>> java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
>> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
>> java.lang.Class.forName0(Native Method) at
>> java.lang.Class.forName(Class.java:264)
>> at
>> com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:4
>> 0)
>> at
>> com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:
>> 669)
>> at
>> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl
>> .java:695)
>> at
>> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(La
>> uncherImpl.java:182)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> Prism pipeline init order: es2 sw
>> Using java-based Pisces rasterizer
>> Using dirty region optimizations
>> Not using texture mask for primitives
>> Not forcing power of 2 sizes for textures
>> Using hardware CLAMP_TO_ZERO mode
>> Opting in for HiDPI pixel scaling
>> Prism pipeline name = com.sun.prism.es2.ES2Pipeline
>> Loading ES2 native library ... prism_es2
>> Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from
>>  relative path succeeded. GLFactory using com.sun.prism.es2.X11GLFactory
>> (X) Got class = class com.sun.prism.es2.ES2Pipeline
>> Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline
>> JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
>

Huge JavaFX performance drop in Debian Jessie

[Chris Newland]

Upgraded my netbook (Intel GMA3150 onboard graphics) from Debian Wheezy to
Debian Jessie and JavaFX performance has suffered a huge drop :(

Possibly not JavaFX related but native apps (firefox etc) all seem to
perform the same and glxgears runs full sync framerate and 350fps
unsynced.

JavaFX stages open blank and can take 5 seconds to render. Trying to
scroll a scrollbar pegs the CPU (java process at 100%) and hangs the app
for 10s+.

Previously stages opened in under 1s and scrolling was instant.

My DemoFX test platform (Canvas based effects) seems to run the same so it
only appears to be windows / stages that are affected.

It's an old (2010) system but JavaFX performance has dropped from slow to
unusable.

Will keep investigating and test on my Debian desktop once I upgrade it to
Jessie.

Cheers,

Chris
@chriswhocodes

JavaFX debug:

Dec 21, 2015 10:35:25 PM com.sun.javafx.jmx.MXExtension initializeIfAvailable
INFO: Failed to initialize management extension
java.lang.ClassNotFoundException: com.oracle.javafx.jmx.MXExtensionImpl
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at 
com.sun.javafx.jmx.MXExtension.initializeIfAvailable(MXExtension.java:40)
at
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:669)
at
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:695)
at
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182)
at java.lang.Thread.run(Thread.java:745)

Prism pipeline init order: es2 sw
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libprism_es2.so from
relative path
succeeded.
GLFactory using com.sun.prism.es2.X11GLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libglass.so from
relative path
Maximum supported texture size: 2048
Non power of two texture support = true
Maximum number of vertex attributes = 16
Maximum number of uniform vertex components = 16384
Maximum number of uniform fragment components = 16384
Maximum number of varying components = 32
Maximum number of texture units usable in a vertex shader = 8
Maximum number of texture units usable in a fragment shader = 8
Graphics Vendor: Intel Open Source Technology Center
   Renderer: Mesa DRI Intel(R) IGD
Version: 2.1 Mesa 10.3.2
 vsync: true vpipe: true
Loaded /home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font.so from
relative path
Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_freetype.so
from relative path
Loaded
/home/chris/jdk1.8.0_66/jre/lib/ext/../amd64/libjavafx_font_pango.so from
relative path
ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag
new alphas
ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag
ES2ResourceFactory: Prism - createStockShader:
Texture_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureFirstPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
Solid_TextureSecondPassLCD.frag
ES2ResourceFactory: Prism - createStockShader:
FillPgram_LinearGradient_PAD.frag
ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag
ES2ResourceFactory: Prism - createStockShader: Mask_TextureSuper.frag
new alphas
new alphas
PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_4

Re: JavaFX on Raspberry Pi

[Chris Newland]

Hi Scott,

If you don't mind the bleeding edge I publish OpenJFX nightlies here for x86 
(Linux and OSX) and ARM (Pi etc)
http://108.61.191.178/

They just unzip over your existing JDK/JRE.

Cheers,

Chris

Sent from my iPhone

> On 6 Dec 2015, at 02:29, Scott Palmer  wrote:
> 
> I seem to recall that the Arm builds of Java 8 no longer include JavaFX.  I 
> just installed 8u65 on my Raspberry Pi and that does in fact appear to be the 
> case.
> 
> The web page 
> https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi was 
> last updated in June and it implies that JavaFX is included in the Java 8 Arm 
> build.  Where do I find the current instructions for getting JavaFX onto a 
> Raspberry Pi?
> 
> Is there anything pre-built available, or am I forced to build it myself with 
> the instructions here: 
> https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float
>  ?
> 
> I’m using a Mac, and the instructions say that mainly Linux is used to 
> cross-build for Arm, so hopefully I won’t get stuck in build hell :-)
> 
> I also noticed that JavaME builds include the Device I/O API  
> (http://docs.oracle.com/javame/8.0/api/dio/api/index.html)
> Is it possible to use these APIs and JavaFX on a Raspberry Pi at the same 
> time?  Can the Device I/O libraries (.jar and .so) simply be copied over from 
> a JavaME install to a JavaSE install?  Do Java 9 modules help with any of 
> that?
> 
> 
> Regards,
> 
> Scott

Re: OpenJFX / JDK 9 questions

[Chris Newland]

Thanks Kevin, Phil.

I find it encouraging that there is a plan to include jfx as part of the
jdk forest as that will lead to a smoother build process.

Hopefully there will still be a mechanism to add OpenJFX to other JDKs
(Zulu etc.) in a post-Jigsaw world.

I filed a bug just as a reminder: Review ID: JI-9023645 and I'll ask over
on jigsaw-dev about possible future mechanisms for adding to a JDK9
installation.

Cheers,

Chris

On Wed, August 19, 2015 17:56, Phil Race wrote:
 On 08/18/2015 03:23 PM, Kevin Rushforth wrote:


 Currently the gradle openZip method makes it easy to create builds
 that unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw
 (JRE)
 structure and doesn't work with JDK9. Shall I submit a bug?

 We are in the process of making major changes for Jigsaw, so anything
 we do for the openZip task will be a stop-gap until that work is
 complete. Go ahead and file the bug, though. If nothing else, it will
 serve as a reminder to test the build with OpenJDK + OpenJFX (without
 either of the closed bits).

 As a general FYI broader than this use case,  as I understand it, the
 modular JDK image is intended to be opaque. The tools that have learned
over
 the years the disk layout  - eg that there is jre/lib/rt.jar will need to
 unlearn that. So overlaying on some expected structure is probably not the
 way to do things in JDK 9. I think you will be expected to use tools to
 build a custom image as opposed to installing over someone else's image. I
 am not the authority on this, but if you want to ask any questions about
 use cases, you should ask on jigsaw-dev.

 -phil.

OpenJFX / JDK 9 questions

[Chris Newland]

Hi,

Please could someone briefly explain the changes to OpenJFX under JDK9 /
modularisation / jigsaw?

I've been trying to answer some questions about this in the London Java
Community (JUG) and have added 8u40 stable binaries to my OpenJFX build
server as that was requested: http://108.61.191.178/

I understand work is already happening under JEP253 to sort out the public
APIs.

Longer term, will OpenJFX ever become a sub-project or module in the
OpenJDK repository?

Is there any plan for a unified build system for OpenJDK and OpenJFX to
produce a binary that runs JavaFX out of the box?

Currently the gradle openZip method makes it easy to create builds that
unpack into OpenJDK / Zulu JDK but this assumes a pre-Jigsaw (JRE)
structure and doesn't work with JDK9. Shall I submit a bug?

Cheers,

Chris

JavaFX amd64 linking against glibc 2.14?

[Chris Newland]

Hi,

I've been testing against JDK 8u60b13 from
https://jdk8.java.net/download.html and it looks like libglass.so in the
Linux 64-bit (amd64) download is now linking against glibc 2.14

JDK 8u45 linked against glibc 2.4

This breaks on Debian (Wheezy) which only provides 2.13-38+deb7u8

Dependency confirmed by running ldd -v on libglass.so

See this thread for details:
https://groups.google.com/forum/#!topic/jitwatch/zzIZcfB_MrA

Is this a bug or a deliberate move?

Thanks,

Chris

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Jim,

Thanks for looking into this.

The patch definitely improves es2 performance on Debian Linux amd64 from
around 33fps to around 53fps for me (nVidia FX580).

I've made patched overlay builds of OpenJFX (Linux) 8 and 9 available on
my OpenJFX CI server for anyone who wants to try it:
http://108.61.191.178/

Will test on OSX tonight.

Cheers,

Chris


On Tue, April 14, 2015 20:16, Jim Graham wrote:
 Hi Chris,


 We identified a fairly localized optimization that we might be able to
 apply to enhance the performance of your Sierpinski program.  We don't have
 any figures yet on whether this will improve other applications/benchmarks
 that people have been discussing, but the improvements with your
 Sierpinski program are quite dramatic on a number
 of platforms and GPUs.

 This issue is now being tracked as:
 https://javafx-jira.kenai.com/browse/RT-40533


 If others could apply the indicated patch to an OpenJFX build and
 provide feedback on any improvements (or bugs!) that they see, that would
 help.  In the meantime, we have a lot of testing to do to verify the
 correctness of the changes...

 ...jim


 On 4/8/15 9:25 AM, Chris Newland wrote:

 Hi Jim,


 I'll post the verbose prism output from my iMac when I get home.


 Just tried this on my Linux workstation and the performance gap is the
 same between es2 and sw so I don't think it's an OSX issue.

 uname -a Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64
 GNU/Linux


 $JAVA_HOME/bin/java -classpath target/DemoFX.jar
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 20
 fps: 31
 fps: 32
 fps: 33
 fps: 35
 fps: 34
 fps: 33


 $JAVA_HOME/bin/java -Dprism.order=sw -classpath target/DemoFX.jar
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 54
 fps: 56
 fps: 60
 fps: 59
 fps: 60
 fps: 61
 fps: 61
 fps: 60


 This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
 graphics card running driver 304.125

 Regards,


 Chris



 On Wed, April 8, 2015 00:16, Jim Graham wrote:

 OK, I took the time to put my rMBP on a diet yesterday and find room
 to install a 10.10 partition.  I get the same numbers for Sierpinski
 on 10.10, so my theory that something changed in the OGL
 implementation for 10.10 doesn't hold water.

 But, I then tried it using the integrated graphics.  I get really
 poor performance using the integrated Intel 4000 graphics, but I get
 great numbers on the discrete nVidia 650m.  It makes sense that the
 Intel
 graphics wouldn't be as powerful as the discrete graphics, but we
 shouldn't be taxing it that much to make that big of a difference.

 Just to be sure - is that iMac a dual graphics system, or is it
 all-AMD-all-the-time?  You can see which GPU is being used if you run
 it with -Dprism.verbose=true...

 ...jim



 On 4/2/15 4:13 PM, Jim Graham wrote:


 On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are
 you running a newer version of MacOS?

 ...jim



 On 3/31/15 3:40 PM, Chris Newland wrote:


 Hi Hervé,



 That's a valid question :)



 Probably because



 a) All my non-UI graphics experience is with immediate-mode /
 raster systems

 b) I'm interested in using JavaFX for particle effects /
 demoscene / gaming so assumed (perhaps wrongly?) that scenegraph
 was not the way to go for that due to the very large number of
 nodes.

 Numbers for my Sierpinski filled triangle example:



 System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
  1024 MB



 java -Dprism.order=es2 -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23
 fps: 18
 fps: 25
 fps: 18
 fps: 23
 fps: 23
 fps: 19
 fps: 25



 java -Dprism.order=sw -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60



 There are never more than 2500 filled triangles on screen. JDK is
  1.8.0_40



 I would say there is a performance problem here? (or at least a
 need for documentation so as to set expectations for
 gc.fillPolygon).

 Best regards,



 Chris






 On Tue, March 31, 2015 22:00, Hervé Girod wrote:


 Why don't you use Nodes rather than Canvas ?




 Sent from my iPhone




 On Mar 31, 2015, at 22:31, Chris Newland
 cnewl...@chrisnewland.com
 wrote:




 Hi Jim,




 Thanks, that makes things much clearer.




 I was surprised how much was going on under the hood of
 GraphicsContext
 and hoped it was just magic glue that gave the best of GPU
 acceleration where available and immediate-mode-like simple
 rasterizing where not.

 I've managed to find an anomaly with
 GraphicsContext.fillPolygon
 where the software pipeline achieves the full 60fps but ES2
 can only manage 30-35fps. It uses lots of overlapping filled
 triangles so I expect suffers from the problem you've
 described.

 SSCCE:
 https://github.com/chriswhocodes/DemoFX/blob/master/src/main/j
 ava/ com/ch

 risnewland/demofx/standalone/Sierpinski.java

 Was full frame rate canvas drawing

Re: Canvas performance on Mac OS

[Chris Newland]

Confirmed, full 60fps performance on 2011 iMac with this fix:

/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java
-cp target/DemoFX.jar com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 23
fps: 19
fps: 26
fps: 21
fps: 21
fps: 26
fps: 17

/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk_PATCHED/Contents/Home/bin/java
-cp target/DemoFX.jar com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 53
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60

I've uploaded OSX SDK overlay builds containing this webrev to
http://108.61.191.178/ if anyone wants to test the fix on their OSX
system.

Thanks a lot Jim and team for looking into this!

Cheers,

Chris


On Thu, April 16, 2015 09:39, Chris Newland wrote:
 Hi Jim,


 Thanks for looking into this.


 The patch definitely improves es2 performance on Debian Linux amd64 from
 around 33fps to around 53fps for me (nVidia FX580).

 I've made patched overlay builds of OpenJFX (Linux) 8 and 9 available on
 my OpenJFX CI server for anyone who wants to try it: http://108.61.191.178/


 Will test on OSX tonight.


 Cheers,


 Chris



 On Tue, April 14, 2015 20:16, Jim Graham wrote:

 Hi Chris,



 We identified a fairly localized optimization that we might be able to
 apply to enhance the performance of your Sierpinski program.  We don't
 have any figures yet on whether this will improve other
 applications/benchmarks that people have been discussing, but the
 improvements with your Sierpinski program are quite dramatic on a number
  of platforms and GPUs.

 This issue is now being tracked as:
 https://javafx-jira.kenai.com/browse/RT-40533



 If others could apply the indicated patch to an OpenJFX build and
 provide feedback on any improvements (or bugs!) that they see, that
 would help.  In the meantime, we have a lot of testing to do to verify
 the correctness of the changes...

 ...jim



 On 4/8/15 9:25 AM, Chris Newland wrote:


 Hi Jim,



 I'll post the verbose prism output from my iMac when I get home.



 Just tried this on my Linux workstation and the performance gap is
 the same between es2 and sw so I don't think it's an OSX issue.

 uname -a Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2
 x86_64 GNU/Linux



 $JAVA_HOME/bin/java -classpath target/DemoFX.jar
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 20
 fps: 31
 fps: 32
 fps: 33
 fps: 35
 fps: 34
 fps: 33



 $JAVA_HOME/bin/java -Dprism.order=sw -classpath target/DemoFX.jar
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
 fps: 56
 fps: 60
 fps: 59
 fps: 60
 fps: 61
 fps: 61
 fps: 60



 This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
 graphics card running driver 304.125

 Regards,



 Chris




 On Wed, April 8, 2015 00:16, Jim Graham wrote:


 OK, I took the time to put my rMBP on a diet yesterday and find
 room to install a 10.10 partition.  I get the same numbers for
 Sierpinski
 on 10.10, so my theory that something changed in the OGL
 implementation for 10.10 doesn't hold water.

 But, I then tried it using the integrated graphics.  I get really
 poor performance using the integrated Intel 4000 graphics, but I get
  great numbers on the discrete nVidia 650m.  It makes sense that
 the Intel
 graphics wouldn't be as powerful as the discrete graphics, but we
 shouldn't be taxing it that much to make that big of a difference.

 Just to be sure - is that iMac a dual graphics system, or is it
 all-AMD-all-the-time?  You can see which GPU is being used if you
 run it with -Dprism.verbose=true...

 ...jim




 On 4/2/15 4:13 PM, Jim Graham wrote:



 On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.
 Are
 you running a newer version of MacOS?

 ...jim




 On 3/31/15 3:40 PM, Chris Newland wrote:



 Hi Hervé,




 That's a valid question :)




 Probably because




 a) All my non-UI graphics experience is with immediate-mode /
 raster systems

 b) I'm interested in using JavaFX for particle effects /
 demoscene / gaming so assumed (perhaps wrongly?) that
 scenegraph was not the way to go for that due to the very large
 number of nodes.

 Numbers for my Sierpinski filled triangle example:




 System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD
 6970M
 1024 MB




 java -Dprism.order=es2 -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23
 fps: 18
 fps: 25
 fps: 18
 fps: 23
 fps: 23
 fps: 19
 fps: 25




 java -Dprism.order=sw -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60




 There are never more than 2500 filled triangles on screen. JDK
 is 1.8.0_40




 I would say there is a performance problem here? (or at least a
  need for documentation so as to set expectations for
 gc.fillPolygon).

 Best regards,




 Chris







 On Tue, March 31, 2015 22:00, Hervé Girod wrote:



 Why don't you use Nodes rather than Canvas ?





 Sent from my iPhone

Private APIs not usable in Java 9?

[Chris Newland]

I just asked about this on the adoption-disc...@openjdk.java.net list and
the answer from Martijn Verburg is:

---
Hi Chris,

I think the strong advice for those using private APIs is to run the jdeps
tool to see where they are using APIs that will go away / be moved. I'd
then get them to post that list to jigsaw-dev, I guess the root cause of
some of these issues should also be logged in JBS and fixed :-).

Cheers,
Martijn
---

If you run $JAVA_HOME/bin/jdeps -jdkinternals class dir or jar then it
will show all uses of JDK private APIs that will go away in JDK9.

An example from one of my own projects:

chris@chris:~$ /home/chris/jdk1.8.0_40/bin/jdeps -jdkinternals
/home/chris/jitwatch/target/jitwatch-1.0.0-SNAPSHOT.jar
jitwatch-1.0.0-SNAPSHOT.jar - /home/chris/jdk1.8.0_40/lib/tools.jar
   org.adoptopenjdk.jitwatch.loader.BytecodeLoader
(jitwatch-1.0.0-SNAPSHOT.jar)
  - com.sun.tools.javap.JavapTask  JDK internal
API (tools.jar)
  - com.sun.tools.javap.JavapTask$BadArgs  JDK internal
API (tools.jar)

Warning: JDK internal APIs are unsupported and private to JDK
implementation that are
subject to be removed or changed incompatibly and could break your
application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

I think sending these reports to jigsaw-...@openjdk.java.net is a
worthwhile effort to help them direct resources for bug fixing and new
public APIs.

Cheers,

Chris

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Jim,

Definitely discrete GPU on the iMac:

java -cp target/DemoFX.jar -Dprism.verbose=true
com.chrisnewland.demofx.standalone.Sierpinski

Prism pipeline init order: es2 sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
succeeded.
GLFactory using com.sun.prism.es2.MacGLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline
Maximum supported texture size: 16384
Maximum texture size clamped to 4096
Non power of two texture support = true
Maximum number of vertex attributes = 16
Maximum number of uniform vertex components = 3072
Maximum number of uniform fragment components = 3072
Maximum number of varying components = 128
Maximum number of texture units usable in a vertex shader = 16
Maximum number of texture units usable in a fragment shader = 16
Graphics Vendor: ATI Technologies Inc.
   Renderer: AMD Radeon HD 6970M OpenGL Engine
Version: 2.1 ATI-1.24.38
 vsync: true vpipe: true
fps: 1
ES2ResourceFactory: Prism - createStockShader: Solid_Color.frag
ES2ResourceFactory: Prism - createStockShader: FillPgram_Color.frag
Loading Prism common native library ...
succeeded.
ES2ResourceFactory: Prism - createStockShader: Texture_Color.frag
ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag
fps: 23
fps: 18
fps: 25
fps: 18
fps: 23
fps: 23
fps: 19
fps: 25
fps: 18

With software pipeline:

java -cp target/DemoFX.jar -Dprism.verbose=true -Dprism.order=sw
com.chrisnewland.demofx.standalone.Sierpinski

Prism pipeline init order: sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
(X) Got class = class com.sun.prism.sw.SWPipeline
Initialized prism pipeline: com.sun.prism.sw.SWPipeline
 vsync: true vpipe: false
fps: 1
Loading Prism common native library ...
succeeded.
fps: 53
fps: 60
fps: 60
fps: 60
fps: 60

But earlier I got similar performance drop for es2 on a Linux system with
discrete Nvidia graphics (see my previous email).

I'll see if I can find a Windows box with discrete graphics to test if all
platforms exhibit this behaviour.

Cheers,

Chris


On Wed, April 8, 2015 00:16, Jim Graham wrote:
 OK, I took the time to put my rMBP on a diet yesterday and find room to
 install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
 so my theory that something changed in the OGL implementation for 10.10
 doesn't hold water.

 But, I then tried it using the integrated graphics.  I get really poor
 performance using the integrated Intel 4000 graphics, but I get great
 numbers on the discrete nVidia 650m.  It makes sense that the Intel
 graphics wouldn't be as powerful as the discrete graphics, but we
 shouldn't be taxing it that much to make that big of a difference.

 Just to be sure - is that iMac a dual graphics system, or is it
 all-AMD-all-the-time?  You can see which GPU is being used if you run it
 with -Dprism.verbose=true...

 ...jim


 On 4/2/15 4:13 PM, Jim Graham wrote:

 On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
 running a newer version of MacOS?

 ...jim


 On 3/31/15 3:40 PM, Chris Newland wrote:

 Hi Hervé,


 That's a valid question :)


 Probably because


 a) All my non-UI graphics experience is with immediate-mode / raster
 systems

 b) I'm interested in using JavaFX for particle effects / demoscene /
 gaming so assumed (perhaps wrongly?) that scenegraph was not the way
 to go for that due to the very large number of nodes.

 Numbers for my Sierpinski filled triangle example:


 System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
 1024 MB


 java -Dprism.order=es2 -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 23
 fps: 18
 fps: 25
 fps: 18
 fps: 23
 fps: 23
 fps: 19
 fps: 25


 java -Dprism.order=sw -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 54
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60


 There are never more than 2500 filled triangles on screen. JDK is
 1.8.0_40


 I would say there is a performance problem here? (or at least a need
 for documentation so as to set expectations for gc.fillPolygon).

 Best regards,


 Chris





 On Tue, March 31, 2015 22:00, Hervé Girod wrote:

 Why don't you use Nodes rather than Canvas ?



 Sent from my iPhone



 On Mar 31, 2015, at 22:31, Chris Newland
 cnewl...@chrisnewland.com
 wrote:



 Hi Jim,



 Thanks, that makes things much clearer.



 I was surprised how much

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Jim,

I'll post the verbose prism output from my iMac when I get home.

Just tried this on my Linux workstation and the performance gap is the
same between es2 and sw so I don't think it's an OSX issue.

uname -a
Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

$JAVA_HOME/bin/java -classpath target/DemoFX.jar
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 20
fps: 31
fps: 32
fps: 33
fps: 35
fps: 34
fps: 33

$JAVA_HOME/bin/java -Dprism.order=sw -classpath target/DemoFX.jar
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 54
fps: 56
fps: 60
fps: 59
fps: 60
fps: 61
fps: 61
fps: 60

This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
graphics card running driver 304.125

Regards,

Chris


On Wed, April 8, 2015 00:16, Jim Graham wrote:
 OK, I took the time to put my rMBP on a diet yesterday and find room to
 install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
 so my theory that something changed in the OGL implementation for 10.10
 doesn't hold water.

 But, I then tried it using the integrated graphics.  I get really poor
 performance using the integrated Intel 4000 graphics, but I get great
 numbers on the discrete nVidia 650m.  It makes sense that the Intel
 graphics wouldn't be as powerful as the discrete graphics, but we
 shouldn't be taxing it that much to make that big of a difference.

 Just to be sure - is that iMac a dual graphics system, or is it
 all-AMD-all-the-time?  You can see which GPU is being used if you run it
 with -Dprism.verbose=true...

 ...jim


 On 4/2/15 4:13 PM, Jim Graham wrote:

 On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
 running a newer version of MacOS?

 ...jim


 On 3/31/15 3:40 PM, Chris Newland wrote:

 Hi Hervé,


 That's a valid question :)


 Probably because


 a) All my non-UI graphics experience is with immediate-mode / raster
 systems

 b) I'm interested in using JavaFX for particle effects / demoscene /
 gaming so assumed (perhaps wrongly?) that scenegraph was not the way
 to go for that due to the very large number of nodes.

 Numbers for my Sierpinski filled triangle example:


 System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
 1024 MB


 java -Dprism.order=es2 -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 23
 fps: 18
 fps: 25
 fps: 18
 fps: 23
 fps: 23
 fps: 19
 fps: 25


 java -Dprism.order=sw -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 54
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60


 There are never more than 2500 filled triangles on screen. JDK is
 1.8.0_40


 I would say there is a performance problem here? (or at least a need
 for documentation so as to set expectations for gc.fillPolygon).

 Best regards,


 Chris





 On Tue, March 31, 2015 22:00, Hervé Girod wrote:

 Why don't you use Nodes rather than Canvas ?



 Sent from my iPhone



 On Mar 31, 2015, at 22:31, Chris Newland
 cnewl...@chrisnewland.com
 wrote:



 Hi Jim,



 Thanks, that makes things much clearer.



 I was surprised how much was going on under the hood of
 GraphicsContext
 and hoped it was just magic glue that gave the best of GPU
 acceleration where available and immediate-mode-like simple
 rasterizing where not.

 I've managed to find an anomaly with GraphicsContext.fillPolygon
 where the software pipeline achieves the full 60fps but ES2 can
 only manage 30-35fps. It uses lots of overlapping filled triangles
 so I expect suffers from the problem you've described.

 SSCCE:
 https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
 com/ch

 risnewland/demofx/standalone/Sierpinski.java

 Was full frame rate canvas drawing an expected use case for
 JavaFX or
 would I be better off with Graphics2D?

 Thanks,



 Chris



 On Mon, March 30, 2015 20:04, Jim Graham wrote:
 Hi Chris,




 drawLine() is a very simple primitive that can be optimized
 with a GPU
 shader.  It either looks like a (potentially rotated) rectangle
 or a rounded rect - and we have optimized shaders for both
 cases.  A large number of drawLine() calls turns into simply
 accumulating a large vertex list and uploading it to the GPU
 with an appropriate shader which is very fast.

 drawPolygon() is a very complex operation that involves things
 like:


 - dealing with line joins between segments that don't exist for
  drawLine() - dealing with only rendering common points of
 intersection once

 To handle all of that complexity we have to involve a
 rasterizer that takes the entire collection of lines, analyzes
 the stroke attributes and interactions and computes a coverage
 mask for each pixel in the region. We do that in software
 currently for all pipelines.

 For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
 CPU path
 rasterization.

 For the SW pipeline, drawLine is a simplified case of
 drawPolygon and so the overhead of lots of calls to drawLine

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Jim,

The first numbers were for my 27 2011 iMac which runs OSX 10.9 Mavericks.

Here are my numbers for a 2013 MacBook Pro (13 Retina) 2.4 GHz Intel Core
i5 / 8GB / Intel Iris 1536 MB / OSX 10.10.2 Yosemite

I don't get 60fps with either pipeline:

java -Dprism.order=es2 -cp target/classes
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 22
fps: 30
fps: 30
fps: 32

java -Dprism.order=sw -cp target/classes
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 28
fps: 34
fps: 33
fps: 34

The OSX Activity Monitor shows the CPU for the Java process near 100% so
it's CPU bound for both pipelines.

On my iMac where I get 60fps with sw pipeline the CPU is only 50%.

I've written a bunch of other JavaFX effects and it's only the routines
that use on strokePolygon and fillPolygon that don't get 60fps once the
polygon count goes above a few hundred.

I've checked the JIT compilation in my application code with JITWatch and
everything is compiled and inlined as I'd expect.

GC logs show a GC every couple of seconds freeing up about 30MB:

13.505: [GC (Allocation Failure) [PSYoungGen: 31983K-96K(36352K)]
37760K-5889K(123904K), 0.0013589 secs] [Times: user=0.00 sys=0.00,
real=0.00 secs]
fps: 32
fps: 32
15.089: [GC (Allocation Failure) [PSYoungGen: 31328K-160K(36352K)]
37121K-5969K(123904K), 0.0008222 secs] [Times: user=0.00 sys=0.00,
real=0.00 secs]
fps: 33
16.683: [GC (Allocation Failure) [PSYoungGen: 30880K-194K(35840K)]
36689K-6011K(123392K), 0.0005803 secs] [Times: user=0.00 sys=0.00,
real=0.00 secs]

I think my question is:

Does the OpenJFX group think JavaFX is a suitable technology for full
frame rate canvas-style graphics or is the degree of indirection between
application code and the graphics hardware just too great?

I would have expected the hardware I've tested on to eat 2500 triangles at
60fps for breakfast even with no GPU acceleration.

I'm going to knock up a version of this code that uses Graphics2D for
comparison.

Cheers,

Chris

On Fri, April 3, 2015 00:13, Jim Graham wrote:
 On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
 running a newer version of MacOS?

 ...jim


 On 3/31/15 3:40 PM, Chris Newland wrote:

 Hi Hervé,


 That's a valid question :)


 Probably because


 a) All my non-UI graphics experience is with immediate-mode / raster
 systems

 b) I'm interested in using JavaFX for particle effects / demoscene /
 gaming so assumed (perhaps wrongly?) that scenegraph was not the way to
 go for that due to the very large number of nodes.

 Numbers for my Sierpinski filled triangle example:


 System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M 1024
 MB


 java -Dprism.order=es2 -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 23
 fps: 18
 fps: 25
 fps: 18
 fps: 23
 fps: 23
 fps: 19
 fps: 25


 java -Dprism.order=sw -cp target/classes/
 com.chrisnewland.demofx.standalone.Sierpinski fps: 1
 fps: 54
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60
 fps: 60


 There are never more than 2500 filled triangles on screen. JDK is
 1.8.0_40


 I would say there is a performance problem here? (or at least a need
 for documentation so as to set expectations for gc.fillPolygon).

 Best regards,


 Chris





 On Tue, March 31, 2015 22:00, Hervé Girod wrote:

 Why don't you use Nodes rather than Canvas ?



 Sent from my iPhone



 On Mar 31, 2015, at 22:31, Chris Newland
 cnewl...@chrisnewland.com
 wrote:



 Hi Jim,



 Thanks, that makes things much clearer.



 I was surprised how much was going on under the hood of
 GraphicsContext
 and hoped it was just magic glue that gave the best of GPU
 acceleration where available and immediate-mode-like simple
 rasterizing where not.

 I've managed to find an anomaly with GraphicsContext.fillPolygon
 where the software pipeline achieves the full 60fps but ES2 can only
 manage 30-35fps. It uses lots of overlapping filled triangles so I
 expect suffers from the problem you've described.

 SSCCE:
 https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/co
 m/ch risnewland/demofx/standalone/Sierpinski.java

 Was full frame rate canvas drawing an expected use case for JavaFX
 or would I be better off with Graphics2D?

 Thanks,



 Chris



 On Mon, March 30, 2015 20:04, Jim Graham wrote:
 Hi Chris,




 drawLine() is a very simple primitive that can be optimized with
 a GPU
 shader.  It either looks like a (potentially rotated) rectangle or
 a rounded rect - and we have optimized shaders for both cases.  A
 large number of drawLine() calls turns into simply accumulating a
 large vertex list and uploading it to the GPU with an appropriate
 shader which is very fast.

 drawPolygon() is a very complex operation that involves things
 like:


 - dealing with line joins between segments that don't exist for
 drawLine() - dealing with only rendering common points of
 intersection once

 To handle all of that complexity we have to involve a rasterizer

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Jim,

Thanks, that makes things much clearer.

I was surprised how much was going on under the hood of GraphicsContext
and hoped it was just magic glue that gave the best of GPU acceleration
where available and immediate-mode-like simple rasterizing where not.

I've managed to find an anomaly with GraphicsContext.fillPolygon where the
software pipeline achieves the full 60fps but ES2 can only manage
30-35fps. It uses lots of overlapping filled triangles so I expect suffers
from the problem you've described.

SSCCE:
https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/chrisnewland/demofx/standalone/Sierpinski.java

Was full frame rate canvas drawing an expected use case for JavaFX or
would I be better off with Graphics2D?

Thanks,

Chris

On Mon, March 30, 2015 20:04, Jim Graham wrote:
 Hi Chris,


 drawLine() is a very simple primitive that can be optimized with a GPU
 shader.  It either looks like a (potentially rotated) rectangle or a
 rounded rect - and we have optimized shaders for both cases.  A large
 number of drawLine() calls turns into simply accumulating a large vertex
 list and uploading it to the GPU with an appropriate shader which is very
 fast.

 drawPolygon() is a very complex operation that involves things like:

 - dealing with line joins between segments that don't exist for
 drawLine() - dealing with only rendering common points of intersection
 once

 To handle all of that complexity we have to involve a rasterizer that
 takes the entire collection of lines, analyzes the stroke attributes and
 interactions and computes a coverage mask for each pixel in the region. We
 do that in software currently for all pipelines.

 For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
 rasterization.

 For the SW pipeline, drawLine is a simplified case of drawPolygon and so
 the overhead of lots of calls to drawLine() dominates its performance.

 I would expect ES2 to blow the SW pipeline out of the water with
 drawLine() performance (as long as there are no additional rendering
 primitives interspersed in the set of lines).

 But, both should be on the same footing for the drawPolygon case.  Does
 the ES2 pipeline compare similarly (hopefully better than) the SW pipeline
 for the polygon case?

 One thing I noticed is that we have no optimized case for drawLine() on
 the SW pipeline.  It generates a path containing a single MOVETO and LINETO
 and feeds it to the generalized path rasterizer when it could instead
 compute the rounded/square rectangle and render it more directly.  If we
 added that support then I'd expect the SW pipeline to perform the set of
 drawLine calls faster than drawPolygon as well...

 ...jim


 On 3/28/15 3:22 AM, Chris Newland wrote:

 Hi Robert,


 I've not filed a Jira yet as I was hoping to find time to investigate
 thoroughly but when I saw your question I thought I'd better add my
 findings.

 I believe the issue is in the ES2Pipeline as if I run with
 -Dprism.order=sw then strokePolygon outperforms the series of strokeLine
  commands as expected:

 java -cp target/DemoFX.jar -Dprism.order=sw
 com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps


 java -cp target/DemoFX.jar -Dprism.order=sw
 com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps


 Will see if I can find the root cause as I've got plenty more examples
 where ES2Pipeline performs horribly on my Mac which should have no
 problem throwing around a few thousand polys.

 I realise there's a *lot* of indirection involved in making JavaFX
 support such a wide range of underlying graphics systems but I do think
 there's a bug here.

 Will file a Jira if I can contribute a bit more than feels slow ;)


 Cheers,


 Chris


 On Sat, March 28, 2015 10:06, Robert Krüger wrote:

 This is consistent with what I am observing. Is this something that
 Oracle
 is aware of? Looking at Jira, I don't see that anyone is working on
 this:


 https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%2
 2In%
 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%2
 0la
 bels%20in%20(performance)

 Given that one of the One of the main reasons to use JFX for me is to
 be able to develop with one code base for at least OSX and Windows and
 the official statement what JavaFX is for, i.e.

 JavaFX is a set of graphics and media packages that enables
 developers to design, create, test, debug, and deploy rich client
 applications that operate consistently across diverse platforms

 and the fact that this is clearly not the case currently (8u40) as
 soon as I do something else than simple forms, I run into
 performance/quality problems on the Mac, I am a bit unsure what to
 make of all that. Is Mac OSX
 a second-class citizen as far as dev resources are concerned?

 Tobi and Chris, have you filed Jira Issues on Mac graphics
 performance that can be tracked?

 I will file an issue with a simple test case and hope for the best

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Hervé,

That's a valid question :)

Probably because

a) All my non-UI graphics experience is with immediate-mode / raster systems

b) I'm interested in using JavaFX for particle effects / demoscene /
gaming so assumed (perhaps wrongly?) that scenegraph was not the way to go
for that due to the very large number of nodes.

Numbers for my Sierpinski filled triangle example:

System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M 1024 MB

java -Dprism.order=es2 -cp target/classes/
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 23
fps: 18
fps: 25
fps: 18
fps: 23
fps: 23
fps: 19
fps: 25

java -Dprism.order=sw -cp target/classes/
com.chrisnewland.demofx.standalone.Sierpinski
fps: 1
fps: 54
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60
fps: 60

There are never more than 2500 filled triangles on screen. JDK is 1.8.0_40

I would say there is a performance problem here? (or at least a need for
documentation so as to set expectations for gc.fillPolygon).

Best regards,

Chris




On Tue, March 31, 2015 22:00, Hervé Girod wrote:
 Why don't you use Nodes rather than Canvas ?


 Sent from my iPhone


 On Mar 31, 2015, at 22:31, Chris Newland cnewl...@chrisnewland.com
 wrote:


 Hi Jim,


 Thanks, that makes things much clearer.


 I was surprised how much was going on under the hood of GraphicsContext
  and hoped it was just magic glue that gave the best of GPU
 acceleration where available and immediate-mode-like simple rasterizing
 where not.

 I've managed to find an anomaly with GraphicsContext.fillPolygon where
 the software pipeline achieves the full 60fps but ES2 can only manage
 30-35fps. It uses lots of overlapping filled triangles so I expect
 suffers from the problem you've described.

 SSCCE:
 https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch
 risnewland/demofx/standalone/Sierpinski.java

 Was full frame rate canvas drawing an expected use case for JavaFX or
 would I be better off with Graphics2D?

 Thanks,


 Chris


 On Mon, March 30, 2015 20:04, Jim Graham wrote:
 Hi Chris,



 drawLine() is a very simple primitive that can be optimized with a
 GPU
 shader.  It either looks like a (potentially rotated) rectangle or a
 rounded rect - and we have optimized shaders for both cases.  A large
  number of drawLine() calls turns into simply accumulating a large
 vertex list and uploading it to the GPU with an appropriate shader
 which is very fast.

 drawPolygon() is a very complex operation that involves things like:

 - dealing with line joins between segments that don't exist for
 drawLine() - dealing with only rendering common points of intersection
  once

 To handle all of that complexity we have to involve a rasterizer that
  takes the entire collection of lines, analyzes the stroke attributes
 and interactions and computes a coverage mask for each pixel in the
 region. We do that in software currently for all pipelines.

 For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
  rasterization.

 For the SW pipeline, drawLine is a simplified case of drawPolygon and
 so the overhead of lots of calls to drawLine() dominates its
 performance.

 I would expect ES2 to blow the SW pipeline out of the water with
 drawLine() performance (as long as there are no additional rendering
 primitives interspersed in the set of lines).

 But, both should be on the same footing for the drawPolygon case.
 Does
 the ES2 pipeline compare similarly (hopefully better than) the SW
 pipeline for the polygon case?

 One thing I noticed is that we have no optimized case for drawLine()
 on the SW pipeline.  It generates a path containing a single MOVETO
 and LINETO and feeds it to the generalized path rasterizer when it
 could instead compute the rounded/square rectangle and render it more
 directly.  If we added that support then I'd expect the SW pipeline to
 perform the set of drawLine calls faster than drawPolygon as well...

 ...jim



 On 3/28/15 3:22 AM, Chris Newland wrote:


 Hi Robert,



 I've not filed a Jira yet as I was hoping to find time to
 investigate thoroughly but when I saw your question I thought I'd
 better add my findings.

 I believe the issue is in the ES2Pipeline as if I run with
 -Dprism.order=sw then strokePolygon outperforms the series of
 strokeLine commands as expected:

 java -cp target/DemoFX.jar -Dprism.order=sw
 com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result:
 44fps



 java -cp target/DemoFX.jar -Dprism.order=sw
 com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result:
 60fps



 Will see if I can find the root cause as I've got plenty more
 examples where ES2Pipeline performs horribly on my Mac which should
 have no problem throwing around a few thousand polys.

 I realise there's a *lot* of indirection involved in making JavaFX
 support such a wide range of underlying graphics systems but I do
 think there's a bug here.

 Will file a Jira if I can contribute a bit more than feels slow

Re: Canvas performance on Mac OS

[Chris Newland]

Hi Robert,

I've not filed a Jira yet as I was hoping to find time to investigate
thoroughly but when I saw your question I thought I'd better add my
findings.

I believe the issue is in the ES2Pipeline as if I run with
-Dprism.order=sw then strokePolygon outperforms the series of strokeLine
commands as expected:

java -cp target/DemoFX.jar -Dprism.order=sw
com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
Result: 44fps

java -cp target/DemoFX.jar -Dprism.order=sw
com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
Result: 60fps

Will see if I can find the root cause as I've got plenty more examples
where ES2Pipeline performs horribly on my Mac which should have no problem
throwing around a few thousand polys.

I realise there's a *lot* of indirection involved in making JavaFX support
such a wide range of underlying graphics systems but I do think there's a
bug here.

Will file a Jira if I can contribute a bit more than feels slow ;)

Cheers,

Chris

On Sat, March 28, 2015 10:06, Robert Krüger wrote:
 This is consistent with what I am observing. Is this something that
 Oracle
 is aware of? Looking at Jira, I don't see that anyone is working on this:

 https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%
 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20la
 bels%20in%20(performance)

 Given that one of the One of the main reasons to use JFX for me is to be
 able to develop with one code base for at least OSX and Windows and the
 official statement what JavaFX is for, i.e.

 JavaFX is a set of graphics and media packages that enables developers
 to design, create, test, debug, and deploy rich client applications that
 operate consistently across diverse platforms

 and the fact that this is clearly not the case currently (8u40) as soon
 as I do something else than simple forms, I run into performance/quality
 problems on the Mac, I am a bit unsure what to make of all that. Is Mac
 OSX
 a second-class citizen as far as dev resources are concerned?

 Tobi and Chris, have you filed Jira Issues on Mac graphics performance
 that can be tracked?

 I will file an issue with a simple test case and hope for the best.





 On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
 cnewl...@chrisnewland.com
 wrote:


 Possibly related:


 I can reproduce a massive (90%) performance drop on OSX between drawing
 a wireframe polygon on a Canvas using a series of gc.strokeLine(double
 x1, double y1, double x2, double y2) commands versus using a single
 gc.strokePolygon(double[] xPoints, double[] yPoints, int count)
 command.

 Creating the polygons manually with strokeLine() is significantly
 faster using the ES2Pipeline on OSX.

 This is reproducible in a little GitHub JavaFX benchmarking project
 I've
 created: https://github.com/chriswhocodes/DemoFX


 Build with ant


 Run with:


 # use strokeLine
 ./run.sh -c 5000 -m line
 result: 60 (sixty) fps


 # use strokePolygon
 ./run.sh -c 5000 -m poly
 result: 6 (six) fps


 System is 2011 iMac 27 / Mavericks / 3.4GHz Core i7 / 20GB RAM /
 Radeon
 6970M 1024MB


 Looking at the code paths in javafx.scene.canvas.GraphicsContext:


 gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE)

 gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true,
 NGCanvas.STROKE_PATH) which involves significantly more work with
 adding to and flushing a GrowableDataBuffer.

 I've not had time to dig any deeper than this but it's surely a bug
 when building a poly manually is 10x faster than using the convenience
 method.

 Cheers,


 Chris


 On Fri, March 27, 2015 21:26, Tobias Bley wrote:

 In my opinion the whole graphics performance on MacOSX isn’t
 good at all with JavaFX….


 Am 27.03.2015 um 22:10 schrieb Robert Krüger
 krue...@lesspain.de:



 The bad full screen performance is without the arcs. It is just one
  call to fillRect, two to strokeOval and one to fillOval, that's
 all. I will build a simple test case and file an issue.

 On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
 james.gra...@oracle.com
 wrote:



 Hi Robert,



 Please file a Jira issue with a simple test case.  Arcs are
 handled as a generalized shape rather than via a predetermined
 shader, but it shouldn't be that slow.  Something else may be
 going on.

 Another test might be to replace the arcs with rectangles or
 ellipses and see if the performance changes...

 ...jim




 On 3/27/15 1:52 PM, Robert Krüger wrote:



 Hi,



 I have a super-simple animation implemented using
 AnimationTimer
 and Canvas where the canvas just performs a few draw operations,
 i.e. fills the screen with a color and then draws and fills 2-3
 circles and I have already observed that each drawing operation
 I add, results in
 significant CPU load (e.g. when I draw  10 arcs in addition to
 the circles, the CPU load goes up to 30-40% on a Mac Book Pro
 for a Canvas size of 600x600(!).



 Now I tested the animation in full screen mode (only

Re: Canvas performance on Mac OS

[Chris Newland]

Possibly related:

I can reproduce a massive (90%) performance drop on OSX between drawing a
wireframe polygon on a Canvas using a series of gc.strokeLine(double x1,
double y1, double x2, double y2) commands versus using a single
gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command.

Creating the polygons manually with strokeLine() is significantly faster
using the ES2Pipeline on OSX.

This is reproducible in a little GitHub JavaFX benchmarking project I've
created: https://github.com/chriswhocodes/DemoFX

Build with ant

Run with:

# use strokeLine
./run.sh -c 5000 -m line
result: 60 (sixty) fps

# use strokePolygon
./run.sh -c 5000 -m poly
result: 6 (six) fps

System is 2011 iMac 27 / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon
6970M 1024MB

Looking at the code paths in javafx.scene.canvas.GraphicsContext:

gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE)

gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true,
NGCanvas.STROKE_PATH) which involves significantly more work with adding
to and flushing a GrowableDataBuffer.

I've not had time to dig any deeper than this but it's surely a bug when
building a poly manually is 10x faster than using the convenience method.

Cheers,

Chris

On Fri, March 27, 2015 21:26, Tobias Bley wrote:
 In my opinion the whole graphics performance on MacOSX isn’t good at
 all with JavaFX….


 Am 27.03.2015 um 22:10 schrieb Robert Krüger krue...@lesspain.de:


 The bad full screen performance is without the arcs. It is just one
 call to fillRect, two to strokeOval and one to fillOval, that's all. I
 will build a simple test case and file an issue.

 On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham james.gra...@oracle.com
 wrote:


 Hi Robert,


 Please file a Jira issue with a simple test case.  Arcs are handled
 as a generalized shape rather than via a predetermined shader, but it
 shouldn't be that slow.  Something else may be going on.

 Another test might be to replace the arcs with rectangles or ellipses
 and see if the performance changes...

 ...jim



 On 3/27/15 1:52 PM, Robert Krüger wrote:


 Hi,


 I have a super-simple animation implemented using AnimationTimer
 and Canvas
 where the canvas just performs a few draw operations, i.e. fills the
  screen with a color and then draws and fills 2-3 circles and I have
 already observed that each drawing operation I add, results in
 significant CPU load (e.g. when I draw  10 arcs in addition to the
 circles, the CPU load goes up to 30-40% on a Mac Book Pro for a
 Canvas size of 600x600(!).


 Now I tested the animation in full screen mode (only with a few
 circles) and playback is unusable for a serious application (very
 choppy). Is 2D canvas performance known to be very bad on Mac or am
 I doing something
 wrong? Are there workarounds for this?

 Thanks,


 Robert





 --
 Robert Krüger
 Managing Partner
 Lesspain GmbH  Co. KG


 www.lesspain-software.com

Re: libjfxmedia.so on armv6hf?

[Chris Newland]

Sorry, I'm a bit confused:

 On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:

 Media and web have not ever been supported or delivered on linux-arm.

So it is possible to build libjfxmedia.so for Linux armv6hf using just
what's in the rt repo?

Thanks,

Chris

On Tue, March 17, 2015 14:46, Kevin Rushforth wrote:
 Not sure what missing stuff you are referring to. All of the JavaFX
 sources for embedded are in the rt repo on openjfx.

 -- Kevin



 Chris Newland wrote:

 Hi Kevin,


 Is there any chance Oracle can release all the missing ARM32 stuff and
 let the community have a go at getting it to work or are there IP /
 licensing issues here?

 I understand that a decision was made to reassign resources but I think
  there's enough brainpower out here in userland to finish the job if
 all the sources were made available.

 Thanks,


 Chris
 @chriswhocodes


 On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:


 Media and web have not ever been supported or delivered on linux-arm.



 Seems that libjfxmedia.so should be excluded by the openZips target.
 David can response further.



 -- Kevin




 Chris Newland wrote:



 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=72026
 7#p7
 20267



 When cross-compiling to armv6hf on an x86-64 Linux system using:



 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:



 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
 object, x86-64, version 1 (SYSV), dynamically linked,
 BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not
 stripped


 Is this a simple gradle error or is it not currently possible to
 build some of the JavaFX libraries for ARM?

 Thanks,



 Chris

Re: libjfxmedia.so on armv6hf?

[Chris Newland]

Hi Kevin,

Is there any chance Oracle can release all the missing ARM32 stuff and let
the community have a go at getting it to work or are there IP / licensing
issues here?

I understand that a decision was made to reassign resources but I think
there's enough brainpower out here in userland to finish the job if all
the sources were made available.

Thanks,

Chris
@chriswhocodes

On Mon, March 16, 2015 23:14, Kevin Rushforth wrote:
 Media and web have not ever been supported or delivered on linux-arm.


 Seems that libjfxmedia.so should be excluded by the openZips target.
 David can response further.


 -- Kevin



 Chris Newland wrote:

 In reference to
 http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p7
 20267


 When cross-compiling to armv6hf on an x86-64 Linux system using:


 gradle clean openZip -PCOMPILE_TARGETS=armv6hf

 Some of the binaries are compiled as x86-64:


 file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

 build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared
 object, x86-64, version 1 (SYSV), dynamically linked,
 BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped


 Is this a simple gradle error or is it not currently possible to build
 some of the JavaFX libraries for ARM?

 Thanks,


 Chris

libjfxmedia.so on armv6hf?

[Chris Newland]

In reference to
http://www.raspberrypi.org/forums/viewtopic.php?f=81t=97367p=720267#p720267

When cross-compiling to armv6hf on an x86-64 Linux system using:

gradle clean openZip -PCOMPILE_TARGETS=armv6hf

Some of the binaries are compiled as x86-64:

file build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so

build/armv6hf-sdk/rt/lib/arm/libjfxmedia.so: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=af8c5754f6a4823ecf22d707b1f604321eb57f22, not stripped

Is this a simple gradle error or is it not currently possible to build
some of the JavaFX libraries for ARM?

Thanks,

Chris

Re: Build farm for OpenJFX (on ARM)

[Chris Newland]

Hi David,

Thanks for the tip, the build server now uses the openZip task and the
bundles appear to be fine when unzipped into a Java installation.

Updated the instructions and it also now creates a build from 9-dev/rt.

http://108.61.191.178/

The intention is still to move this over to Adoption Group's CloudBees but
for now this helps IoT ARM JDKs to get OpenJFX support.

Cheers,

Chris


On Wed, March 11, 2015 16:36, David Hill wrote:
 On 3/9/15, 5:00 AM, Chris Newland wrote:

 Hi all,


 A quick update on this:


 There are a small number of wrinkles before we get OpenJFX building on
 the Adoption group's CloudBees system so I've put together a
 Debian-based VPS
 server that is producing nightly OpenJFX builds for Linux amd64 and
 armv6hf.

 It updates fromhttp://hg.openjdk.java.net/openjfx/8u-dev/rt  and pulls
 the latest crosslibs dependencies before building so it's the bleeding
 edge of the OpenJFX codebase.
 Chris,
 I forgot to blast this out to the group:


 gradle openZip

 which is part of gradle zip -or-
 gradle all at least in the open builds.

 This target was added a month or so ago, and I just fixed  something in
 in, that meant it was not showing up in openZip properly.

 This target builds a bundle in
 ./builds/[platform-]bundles/javafx-sdk-overlay.zip


 The contents include jfxrt.jar which has been filtered in a similar
 fashion to the JFX product, removing some stuff that is not appropriate
 to a given platform. (Yes that means Monocle on non-arm platforms). The
 logic is pretty straight forward - ie Windows classes don't show up on a
 non-windows platform.

 The resulting bundle *should* be able to be deployed by just unpacking it
 over a JDK, which is intended to simplify matters.

 Dave



 --
 David Hilldavid.h...@oracle.com
 Java Embedded Development


 A man's feet should be planted in his country, but his eyes should
 survey the world. -- George Santayana (1863 - 1952)

Re: Build farm for OpenJFX (on ARM)

[Chris Newland]

Hi Martijn,

I have Role: Observer for Adopt OpenJDK and I don't see any edit buttons
so guess I'm not permitted ;)

There's already a very good wiki for OpenJFX here
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX so maybe
Adopt should link to that?

Mani's been chipping away at the hurdles to get OpenJFX working on the
Adopt CloudBees but we're stuck on a darned Fedora/freetype dependency at
the moment so I've put this personal VPS together as a stop gap.

I've pushed a little JavaFX benchmark framework to do some performance
measurements https://github.com/chriswhocodes/DemoFX and have found one
possible perf bug for which I'll submit a patch if confirmed.

Hopefully this little framework will lower the bar for people to play with
JavaFX as you just need to implement a single render() method.

Maybe I could do a JavaFX demoscene hacking tutorial at the next
Hack-the-Tower meetup?

Cheers,

Chris

On Mon, March 9, 2015 09:41, Martijn Verburg wrote:
 Hi Chris,


 Just to add to this, have you got an account to edit the wiki at
 adoptopenjdk.java.net?  We should add a link to this build from there.

 Cheers,
 Martijn


 On 9 March 2015 at 09:00, Chris Newland cnewl...@chrisnewland.com
 wrote:


 Hi all,


 A quick update on this:


 There are a small number of wrinkles before we get OpenJFX building on
 the Adoption group's CloudBees system so I've put together a
 Debian-based VPS
 server that is producing nightly OpenJFX builds for Linux amd64 and
 armv6hf.

 It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls
 the latest crosslibs dependencies before building so it's the bleeding
 edge of the OpenJFX codebase.

 The build log shows failing tests for LinuxDebBundlerTest which I need
 to fix but working binaries are still produced.

 http://108.61.191.178/


 No domain name yet as this is just a temporary home.


 Oracle - please shout if there are any license issues with me doing
 this?

 Cheers,


 Chris

Re: Build farm for OpenJFX (on ARM)

[Chris Newland]

Hi all,

A quick update on this:

There are a small number of wrinkles before we get OpenJFX building on the
Adoption group's CloudBees system so I've put together a Debian-based VPS
server that is producing nightly OpenJFX builds for Linux amd64 and
armv6hf.

It updates from http://hg.openjdk.java.net/openjfx/8u-dev/rt and pulls the
latest crosslibs dependencies before building so it's the bleeding edge of
the OpenJFX codebase.

The build log shows failing tests for LinuxDebBundlerTest which I need to
fix but working binaries are still produced.

http://108.61.191.178/

No domain name yet as this is just a temporary home.

Oracle - please shout if there are any license issues with me doing this?

Cheers,

Chris

Re: DemoFX - JavaFX examples / benchmarking framework

[Chris Newland]

Hi Benjamin,

Thanks :)

I'll definitely be looking at scene graph when I do some 3D effects.

Cheers,

Chris
@chriswhocodes

On Mon, March 9, 2015 08:36, Benjamin Gudehus wrote:
 Hi Chris,


 that's amazing. Would it be possible in the future to allow both Canvas
 and Shapes (in a Scene graph)?


 --Benjamin



 On Mon, Mar 9, 2015 at 9:11 AM, Chris Newland cnewl...@chrisnewland.com
  wrote:


 Hi all,


 I've put together a little framework called DemoFX and a few
 demoscene
 graphical effects for measuring JavaFX performance:

 https://github.com/chriswhocodes/DemoFX


 Here's a YouTube video of some of the effects I've developed:


 https://www.youtube.com/watch?v=N1rihYA8c2M (watch in HD if you can)


 There's an abstract base class that takes care of the setup and
 measures frame rate and time spent in the render() method so developing
 new effects is quite easy. I plan to add some text-based effects and
 also some 3D stuff.

 It's all Canvas based and the effects are rendered with calls to
 GraphicsContext. It seems to run at 60fps on modern hardware with the
 ES2Pipeline (once it's run enough loops for the JIT compilers to do
 their thing).

 I think I've already found one JavaFX performance problem:


 GraphicsContext's strokePolygon(pointsX, pointsY, count) has about half
  the performance of the equivalent set of strokeLine(x1, y1, x2, y2)
 commands.

 Example (after building DemoFX with ant)


 ./run.sh -m line
 vs ./run.sh -m poly


 Will do a full write-up later.


 Cheers,


 Chris
 @chriswhocodes

Build farm for OpenJFX (on ARM)

[Chris Newland]

Hi Johan, all,

Following the announcement that JDK builds for ARM will no longer include
JavaFX I started talking with the OpenJDK Adoption group
(https://wiki.openjdk.java.net/display/Adoption/Main) about the
possibility of using their CloudBees CI system to produce OpenJFX binaries
(for all operating systems including ARM) as a way to help keep JavaFX
alive on IoT devices.

For those who don't know the Adoption group, its mission is to help
developers get started with building OpenJDK, testing new features,
submitting bug reports, and cleaning up code.

Adoption has a CloudBees CI set up and I've been talking with Mani Sarkar
(@theneomatrix369) about setting up an OpenJFX CI project with
cross-compile support that builds OpenJFX for all archs.

The cross-compile instructions here
https://wiki.openjdk.java.net/display/OpenJFX/Cross+Building+for+ARM+Hard+Float
are working great for me locally so now we're trying to work out how to
move that to the cloud.

I don't want to tread on anyone's toes here and we're not trying to become
any kind of official source for JavaFX, just trying to make sure there's
an easy way (e.g. binaries) for end users to add JavaFX to their ARM JDKs
and to help people dip their toes into OpenJFX development as per the
Adoption group's mission.

Happy to coordinate on how we can make this useful and avoid any
duplication of effort :)

Personally, I'm a big fan of JavaFX and use it as the UI layer in JITWatch
 (https://github.com/AdoptOpenJDK/jitwatch/). I'm also into IoT and
wearables and think JavaFX would be great on the new Raspberry Pi 2.

Cheers,

Chris
@chriswhocodes

Quick look at JavaFX methods above the HotSpot inlining threshold

[Chris Newland]

Hi all,

As part of the JITWatch[1] project I've written a tool called JarScan
which counts the bytecode size of methods in a jar and logs those methods
which are above HotSpot's 325 byte size threshold for inlining methods it
determines are hot.

In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774
methods above the threshold which I've listed in this gist:
https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2

A lot of these won't be found in hot code but perhaps the methods under
com.sun.javafx.geom and javafx.scene.transform could be candidates for
examination with JIT compilation in mind?

Has anybody on the list done any experiments in this area? If not I'll try
and find some time to see if there are any gains to be made by trimming
methods (in the OpenJFX source) to fit inside the inlining threshold.

Cheers,

Chris
@chriswhocodes

[1] https://github.com/AdoptOpenJDK/jitwatch

Re: OT: Netbeans ported to JFX?

[Chris Newland]

Apologies for the self-promotion but I've built a pretty complex open
source project using JavaFX and found it to be a very usable technology.

Light years ahead of Swing and more powerful than SWT; much easier layout
(VBox/HBox), builder pattern, styling (CSS etc.) and deployment (part of
JRE).

The project is a HotSpot LogCompilation analyser called JITWatch (an
AdoptOpenJDK project) and it uses a range of JavaFX controls and features
(TreeViews, SplitPanes, Canvas, etc.)

There are some screenshots at the end of the wiki at
https://github.com/AdoptOpenJDK/jitwatch/wiki

I wouldn't go back to SWT now I'm up to speed with JavaFX and would
definitely use it commercially.

Cheers,

Chris
@chriswhocodes

On Thu, July 10, 2014 15:53, David Hill wrote:

 It certainly would be nice to have more JavaFX applications (real apps or
 even good demos) as it would help showcase the capabilities. Jasper has
 whipped together some interesting demo apps over the years for JavaOne

 Any suggestions on good demo apps for small boards (Pi, i.MX6) ?
 (Existing or otherwise).


 Dave