Re: armv6hf build failing with multiple definition of `JNI_OnLoad'
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'
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
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
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.
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)
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 > etc
Re: Error on build
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 :
>
>
> 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 usin
Re: Error on build
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)
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?
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
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)
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
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
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?
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
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
k(Native 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.Quan
Huge JavaFX performance drop in Debian Jessie
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
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
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
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?
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
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
Re: Canvas performance on Mac OS
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 >>>>
Private APIs not usable in Java 9?
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 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
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 &g
Re: Canvas performance on Mac OS
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 >>>>> >>>>> 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 ac
Re: Canvas performance on Mac OS
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 >>>> >>>> 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 >>>&
Re: Canvas performance on Mac OS
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 >> 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 Robe
Re: Canvas performance on Mac OS
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 an
Re: Canvas performance on Mac OS
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 > > 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 >>>> : >>>> >>>> >>>> >>>> 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 >>>> >>>> wrote: >>>> >>>>
Re: Canvas performance on Mac OS
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 : >> >> >> 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 >> 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?
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=81&t=97367&p=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?
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=81&t=97367&p=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?
In reference to http://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=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)
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 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: Build farm for OpenJFX (on ARM)
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 > 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: DemoFX - JavaFX examples / benchmarking framework
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 > 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 >> >> >> >
Re: Build farm for OpenJFX (on ARM)
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
DemoFX - JavaFX examples / benchmarking framework
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)
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
Re: JavaFX embedded (graphics example / performance test)
Hi Felix, This looks like a really interesting project. I'm starting to investigate JavaFX performance from a JIT compilation viewpoint to make sure there are no areas in the codebase that are defeating the HotSpot JIT compilers. I've written a couple of Canvas-based "demoscene" style animations but not tried anything with Nodes yet. Will definitely be keeping an eye on FXMark. Cheers, Chris @chriswhocodes On Wed, December 10, 2014 20:26, Felix Bembrick wrote: > Hi Prasant, > > > I have been working on just such a beast for much longer than I had > intended (family commitments, illness, wedding to organise, you know) > which I call *FXMark*. > > > I had originally intended to release *FXMark* earlier this year but in > reality it won't be out there until after my wedding in January. However, > it will be a much more sophisticated animal and will really highlight > what can be done with animations of nodes in the scenegraph along with > permitting observation of the effects of applying various effects and > caching strategies. > > I am sorry I cannot give you an official release date but expect it > sometime in the New Year. > > You can read a little but about it and see more about me at my blog > http://justmy2bits.com > > > Cheers, > > > Felix > > > > On 11 December 2014 at 00:05, Prasant J wrote: > > >> Hi, >> >> >> Is there any JavaFX test program that can be used for >> testing/comparing graphics performance? >> >> >> Regards, Pj >> >> >
Window decoration bug on Yosemite?
Hi, I think there might be a bug with the window decoration on OSX Yosemite whenever the StageStyle is set to UTILITY: initStyle(StageStyle.UTILITY); The red close icon appears twice. Once on the left as expected but again in the right most position where the green maximise icon should be. Screenshot here: https://github.com/AdoptOpenJDK/jitwatch/issues/135 Bug occurs in: Oracle 1.7.0_72 Oracle 1.8.0_25 Oracle 1.8.0_40ea OpenJDK 1.9.0 I've had a look around in the OpenJFX source but haven't been able to track down the cause yet. Kind regards, Chris @chriswhocodes
Re: Quick look at JavaFX methods above the HotSpot inlining threshold
Hi Scott, MaxInlineSize (default 35) is the size under which methods will be inlined regardless of whether they meet the "hot" criteria (number of invocations observed; 10,000 for server VM). FreqInlineSize (default 325 on Linux x86_64) is the size up to which HotSpot will inline methods if they meet the "hot" criteria. Documentation on these is bit sparse but they are defined in hotspot/src/cpu/x86/vm/c1_globals_x86.hpp in the OpenJDK source code. >From my experiments, tuning (increasing) these parameters can often worsen overall application behaviour, probably because they were arrived at empirically after profiling the core libs. In some of the core libs, method bytecode is pushed above the inling threshold by assert code that under most conditions (no -ea VM switch) will never be executed. I've seen assertions account for up to 25% of a method's bytecode. JITWatch has a "Sandbox" mode where you can rapidly profile the effects of tuning these parameters and can also highlight badly predicted branches and polymorphic dispatches (which can't be type-sharpened). I think it will be interesting to run JITWatch over some JavaFX applications as graphics code can have some really hot loops where small gains can make a difference. I can't promise any performance silver bullets and this is observation is only about inlining (saving the method invocation overhead). Hot code will still be JIT-compiled to native even if it's above the FreqInlineSize threshold (in fact I've seen some UI blit methods generate >32KBytes of native code thanks to some aggressive loop unrolling!). Will let you know what I find. Cheers, Chris @chriswhocodes p.s. the JITWatch UI is written in JavaFX and I've found it a really nice technology to work with :) On Tue, November 4, 2014 02:05, Scott Palmer wrote: > JITWatch looks like an interesting project. > > > Where did you get the information about the 325 byte limit? The data I > found indicated that the default limit was *much* smaller. > > From this page: > http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BA > BDDFII > > > -XX:MaxInlineSize=size > Sets the maximum bytecode size (in bytes) of a method to be inlined. > Append the letter k or K to indicate kilobytes, m or M to indicate > megabytes, g or G to indicate gigabytes. By default, the maximum bytecode > size is set to 35 bytes: > > -XX:MaxInlineSize=35 > > > > It would be interesting to see how adjusting some of those parameters > affects performance. Does JITWatch have tools for measuring that sort of > thing? > > Cheers, > > > Scott > > > >> On Nov 3, 2014, at 6:42 PM, Chris Newland >> wrote: >> >> >> 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 >> >> > >
Quick look at JavaFX methods above the HotSpot inlining threshold
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?
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 >
