From ddudouit at clio.ch  Wed Apr  1 09:42:25 2015
From: ddudouit at clio.ch (Damien Dudouit)
Date: Wed, 1 Apr 2015 11:42:25 +0200
Subject: Canvas : 2 pixel thick line width
Message-ID: <CAAJRru014qW3DD-FUyOGvV-t6-bNuKFp6_C1soGiXvd+pHiQag@mail.gmail.com>

Hello,

I'm using a Canvas to display some content (mostly text with lines also for
underline).

I've just noticed something that is a big problem for me : with
line-width=1 and no scaling, actual line-width on display takes 2 pixels.

    Canvas canvas = new Canvas(300, 300);
    GraphicsContext gc = canvas.getGraphicsContext2D();
    gc.setStroke(Color.BLACK);
    gc.setLineWidth(1);
    gc.strokeLine(10, 10, 110, 10);

I'm running Win7 64bits and I have made the test with Oracle jdk8_40 and
jdk7_71 and the result is the same.

That 2 pixel thick line is not perfectly black but dark gray.
If I do 'gc.setLineWidth(2)', then I get a 2 pixel thick line perfectly
black.
If I do 'gc.setLineWidth(0.5)', then I get a 2 pixel thick line with a
lighter gray.

I want to display underline text in the canvas and a 2 pixel thick
underline looks bad.

Any help would be greatly appreciated.

Damien

From ddudouit at clio.ch  Wed Apr  1 10:14:15 2015
From: ddudouit at clio.ch (Damien Dudouit)
Date: Wed, 1 Apr 2015 12:14:15 +0200
Subject: Canvas : 2 pixel thick line width
In-Reply-To: <CAAJRru014qW3DD-FUyOGvV-t6-bNuKFp6_C1soGiXvd+pHiQag@mail.gmail.com>
References: <CAAJRru014qW3DD-FUyOGvV-t6-bNuKFp6_C1soGiXvd+pHiQag@mail.gmail.com>
Message-ID: <CAAJRru1qEfaTCa9tdk58A9=7fNu8HSPvEmitwWUYc1cskcP3Aw@mail.gmail.com>

Hello,

I have found the following answer :

http://stackoverflow.com/questions/27846659/how-to-draw-an-1-pixel-line-using-javafx-canvas

*Imagine each pixel as a (small) rectangle (instead of a point). The
integer coordinates are the boundaries between pixels; so a (horizontal or
vertical) line with integer coordinates falls "between pixels". This is
rendered via antialising, approximating half of the line on one pixel and
half on the other. Moving the line 0.5 pixels left or right moves it to the
center of the pixel, getting around the issue.*


I have done quite a bit of custom controls drawing (canvas) with swing and
swt and it's quite a shift of approach that plain coordinates to not match
pixels on display.

In swing/swt, if I want to draw a rectangle from pixel (0,0) to pixel
(2,2), ie. a square of 3x3 pixels I do :
gc.drawRectangle(0, 0, 3, 3); // x, y, width, height

In JavaFX I must do :
gc.strokeRect(0.5, 0.5, 2, 2)

Have a good day,

Damien

2015-04-01 11:42 GMT+02:00 Damien Dudouit <ddudouit at clio.ch>:

> Hello,
>
> I'm using a Canvas to display some content (mostly text with lines also
> for underline).
>
> I've just noticed something that is a big problem for me : with
> line-width=1 and no scaling, actual line-width on display takes 2 pixels.
>
>     Canvas canvas = new Canvas(300, 300);
>     GraphicsContext gc = canvas.getGraphicsContext2D();
>     gc.setStroke(Color.BLACK);
>     gc.setLineWidth(1);
>     gc.strokeLine(10, 10, 110, 10);
>
> I'm running Win7 64bits and I have made the test with Oracle jdk8_40 and
> jdk7_71 and the result is the same.
>
> That 2 pixel thick line is not perfectly black but dark gray.
> If I do 'gc.setLineWidth(2)', then I get a 2 pixel thick line perfectly
> black.
> If I do 'gc.setLineWidth(0.5)', then I get a 2 pixel thick line with a
> lighter gray.
>
> I want to display underline text in the canvas and a 2 pixel thick
> underline looks bad.
>
> Any help would be greatly appreciated.
>
> Damien
>

From tomas.mikula at gmail.com  Wed Apr  1 17:44:30 2015
From: tomas.mikula at gmail.com (Tomas Mikula)
Date: Wed, 1 Apr 2015 13:44:30 -0400
Subject: How to tell if KEY_PRESSED comes with a corresponding KEY_TYPED?
Message-ID: <CA+THrupOkTOQtFbyk8YNv3W073vCtZOp3zd62fzEaZRZ-VsvpA@mail.gmail.com>

On character input, two events are fired: KEY_PRESSED and KEY_TYPED.
When my control is interested in the characters, KEY_TYPED should be
handled, because it contains the entered Unicode characters. In that
case, however, I would also like to consume the corresponding
KEY_PRESSED event, so that it does not bubble up the scene graph.

A user reported an instance of this problem with my RichTextFX control
placed inside a ScrollPane: when spacebar was pressed, a space was
inserted in the text area *and* the ScrollPane scrolled down. This
happened because RichTextFX handled the KEY_TYPED event, but let the
KEY_PRESSED bubble up and ScrollPane handled the KEY_PRESSED event.

I can fix the above case by RichTextFX consuming KEY_PRESSED events
whose key code isLetterKey(), isDigitKey() or isWhitespaceKey(), but
it is not a general solution: it would still not work if ScrollPane
used e.g. '[' and ']' to scroll up and down.

My question is, is there a general solution for this kind of problem?

Given a KEY_PRESSED event, being able to tell whether there is a
corresponding KEY_TYPED event generated would solve the problem, but
it is currently not possible AFAIK.

Regards,
Tomas

From krueger at lesspain.de  Wed Apr  1 19:23:18 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 1 Apr 2015 21:23:18 +0200
Subject: Media API question regarding metadata retrieval
Message-ID: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>

Hi,

I was a bit surprised that the metadata retrieval functionality
of javafx.scene.media.Media is only usable in conjunction with a player, so
if I want to retrieve the dimensions of a video file I have to instantiate
a player and wait for it to reach ready state? That's how I read the
javadoc. Is this a misunderstanding? If not is there a specific reason not
to offer this functionality independently of a player?

Best regards,

Robert

From david.dehaven at oracle.com  Wed Apr  1 19:48:55 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 1 Apr 2015 12:48:55 -0700
Subject: Media API question regarding metadata retrieval
In-Reply-To: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
Message-ID: <F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>


> I was a bit surprised that the metadata retrieval functionality
> of javafx.scene.media.Media is only usable in conjunction with a player, so
> if I want to retrieve the dimensions of a video file I have to instantiate
> a player and wait for it to reach ready state? That's how I read the
> javadoc. Is this a misunderstanding?

Nope, currently you have to create a player. Once a player is created it kicks off a parser to grab metadata or waits for the underlying native player to parse.


> If not is there a specific reason not
> to offer this functionality independently of a player?

There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java based parser, but honestly, who's using that these days?

-DrD-


From swpalmer at gmail.com  Wed Apr  1 20:50:44 2015
From: swpalmer at gmail.com (Scott Palmer)
Date: Wed, 1 Apr 2015 16:50:44 -0400
Subject: Media API question regarding metadata retrieval
In-Reply-To: <F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
Message-ID: <CAL3e5iGV49o+mKnigCDCRyU1wXxWgrs-JTnE0yRjDcf+khv9AA@mail.gmail.com>

I seems like a decent compromise to defer to the native platform code that
will ultimately be used to process the file anyway.  It seems a little
heavy, but the alternative is perhaps bloating the JavaFX API.

It likely makes more sense to use the MediaInfo project with some JNA
bindings (you can probably find either JNI or JNA bindings on the web) if
you need access to the metadata:
https://mediaarea.net/nn/MediaInfo

I keep thinking a pure java port of MediaInfo would be cool... but probably
not worth the time :-)

Scott


On Wed, Apr 1, 2015 at 3:48 PM, David DeHaven <david.dehaven at oracle.com>
wrote:

>
> > I was a bit surprised that the metadata retrieval functionality
> > of javafx.scene.media.Media is only usable in conjunction with a player,
> so
> > if I want to retrieve the dimensions of a video file I have to
> instantiate
> > a player and wait for it to reach ready state? That's how I read the
> > javadoc. Is this a misunderstanding?
>
> Nope, currently you have to create a player. Once a player is created it
> kicks off a parser to grab metadata or waits for the underlying native
> player to parse.
>
>
> > If not is there a specific reason not
> > to offer this functionality independently of a player?
>
> There were plans, there were also issues as we don't have a Java based mp4
> parser so we're relying on the underlying platforms (e.g. QTKit,
> AVFoundation, etc..) to provide that data, which basically means we're
> creating a player at the native level anyways. If you're using the horribly
> outdated FXM format you get the benefit of a Java based parser, but
> honestly, who's using that these days?
>
> -DrD-
>
>

From Fabrizio.Giudici at tidalwave.it  Thu Apr  2 00:05:33 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Thu, 02 Apr 2015 02:05:33 +0200
Subject: Media API question regarding metadata retrieval
In-Reply-To: <CAL3e5iGV49o+mKnigCDCRyU1wXxWgrs-JTnE0yRjDcf+khv9AA@mail.gmail.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
	<CAL3e5iGV49o+mKnigCDCRyU1wXxWgrs-JTnE0yRjDcf+khv9AA@mail.gmail.com>
Message-ID: <op.xwfujjyc2ilaq7@localhost>

On Wed, 01 Apr 2015 22:50:44 +0200, Scott Palmer <swpalmer at gmail.com>  
wrote:

> I seems like a decent compromise to defer to the native platform code  
> that
> will ultimately be used to process the file anyway.  It seems a little
> heavy, but the alternative is perhaps bloating the JavaFX API.
>
> It likely makes more sense to use the MediaInfo project with some JNA
> bindings (you can probably find either JNI or JNA bindings on the web) if
> you need access to the metadata:
> https://mediaarea.net/nn/MediaInfo
>
> I keep thinking a pure java port of MediaInfo would be cool... but  
> probably
> not worth the time :-)

There are some pure Java media parsers around; the problem is that one  
should check whether they are complete, that is whether they support all  
the kinds of media one needs. For instance, at the moment I'm using  
Jaudiotagger.


-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From krueger at lesspain.de  Thu Apr  2 07:23:09 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 2 Apr 2015 09:23:09 +0200
Subject: Media API question regarding metadata retrieval
In-Reply-To: <F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
Message-ID: <CAEnqZEV8QF2=FHU=oSJz84sJAyQMeZVb_YjLgSONnuFBjDah3w@mail.gmail.com>

On Wed, Apr 1, 2015 at 9:48 PM, David DeHaven <david.dehaven at oracle.com>
wrote:

>
> > I was a bit surprised that the metadata retrieval functionality
> > of javafx.scene.media.Media is only usable in conjunction with a player,
> so
> > if I want to retrieve the dimensions of a video file I have to
> instantiate
> > a player and wait for it to reach ready state? That's how I read the
> > javadoc. Is this a misunderstanding?
>
> Nope, currently you have to create a player. Once a player is created it
> kicks off a parser to grab metadata or waits for the underlying native
> player to parse.
>
>
> > If not is there a specific reason not
> > to offer this functionality independently of a player?
>
> There were plans, there were also issues as we don't have a Java based mp4
> parser so we're relying on the underlying platforms (e.g. QTKit,
> AVFoundation, etc..) to provide that data, which basically means we're
> creating a player at the native level anyways. If you're using the horribly
> outdated FXM format you get the benefit of a Java


Deferring to native code absolutely makes sense but I didn't think that you
needed to create a player to obtain duration, width and height in
AVFoundation either.

From krueger at lesspain.de  Thu Apr  2 07:33:31 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 2 Apr 2015 09:33:31 +0200
Subject: Media API question regarding metadata retrieval
In-Reply-To: <CAL3e5iGV49o+mKnigCDCRyU1wXxWgrs-JTnE0yRjDcf+khv9AA@mail.gmail.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
	<CAL3e5iGV49o+mKnigCDCRyU1wXxWgrs-JTnE0yRjDcf+khv9AA@mail.gmail.com>
Message-ID: <CAEnqZEXFcV-hjVK1iObp3wDZGNCGFAuvcje5jsPK1erUbJvNZg@mail.gmail.com>

On Wed, Apr 1, 2015 at 10:50 PM, Scott Palmer <swpalmer at gmail.com> wrote:

> I seems like a decent compromise to defer to the native platform code that
> will ultimately be used to process the file anyway.  It seems a little
> heavy, but the alternative is perhaps bloating the JavaFX API.
>
>
Yes absolutely but ... (see my reply to David).


> It likely makes more sense to use the MediaInfo project with some JNA
> bindings (you can probably find either JNI or JNA bindings on the web) if
> you need access to the metadata:
> https://mediaarea.net/nn/MediaInfo
>
>
Yes, also agreed for real general-purpose metadata retrieval like in a
broadcast or media converter product, it does not make sense to kick off
such a huge project in Java, when there is already native code around for
that and we are doing that already in one of our products using JNI. I am
talking about the super-simple cases where I am fine with the (very
limited) format support of JavaFX and I just want to know duration, width
and height basically for those files and I do not want to ship native libs
with my cross-platform app which otherwise works well enough with pure
Java. I just don't see any technical reason to instantiate a player for
that in any native framework I know and it should not be necessary in
JavaFX IMHO. Of course I can wrap all that in my own library and probably
will and then the fact that a player is instantiated and then thrown away
is just an implementation detail, I just did not and still do not see why
this is necessary or sensible, which is why I asked.


> I keep thinking a pure java port of MediaInfo would be cool... but
> probably not worth the time :-)
>
>
Yes, I agree and it's doable but A LOT of work (if you want to have the
level of completeness and maturity of MediaInfo) and therefore not likely
to happen anytime soon.

From elina.kleyman at oracle.com  Thu Apr  2 13:42:37 2015
From: elina.kleyman at oracle.com (Elina Kleyman)
Date: Thu, 2 Apr 2015 06:42:37 -0700 (PDT)
Subject: [8u60] Review request: RT-40184 - Remove use of internal classes
	methods from samples
Message-ID: <222f4a6a-5e6c-4c42-b0b0-8d4b59be9b8f@default>

Hi Kevin, Chien,

 

Please review fix for https://javafx-jira.kenai.com/browse/RT-40184

Link to webrev: http://cr.openjdk.java.net/~ekleyman/RT-40184/

 

Thanks,

Elina

 

From david.dehaven at oracle.com  Thu Apr  2 16:16:23 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 2 Apr 2015 09:16:23 -0700
Subject: Media API question regarding metadata retrieval
In-Reply-To: <CAEnqZEV8QF2=FHU=oSJz84sJAyQMeZVb_YjLgSONnuFBjDah3w@mail.gmail.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
	<CAEnqZEV8QF2=FHU=oSJz84sJAyQMeZVb_YjLgSONnuFBjDah3w@mail.gmail.com>
Message-ID: <A2EF3E98-9F24-4E4C-9669-0359BA6970EE@oracle.com>


> > If not is there a specific reason not
> > to offer this functionality independently of a player?
> 
> There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java 
> 
> Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either.

No, but for the lack of a separate interface for metadata retrieval. In hindsight there were a number of things that should have been done differently :/

-DrD-


From krueger at lesspain.de  Thu Apr  2 16:24:43 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 2 Apr 2015 18:24:43 +0200
Subject: Media API question regarding metadata retrieval
In-Reply-To: <A2EF3E98-9F24-4E4C-9669-0359BA6970EE@oracle.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
	<CAEnqZEV8QF2=FHU=oSJz84sJAyQMeZVb_YjLgSONnuFBjDah3w@mail.gmail.com>
	<A2EF3E98-9F24-4E4C-9669-0359BA6970EE@oracle.com>
Message-ID: <CAEnqZEUsaXWpMroqM_=iiHwy6CSBRRzHkhoO01mgzj4RgE-G7g@mail.gmail.com>

On Thu, Apr 2, 2015 at 6:16 PM, David DeHaven <david.dehaven at oracle.com>
wrote:

>
> > > If not is there a specific reason not
> > > to offer this functionality independently of a player?
> >
> > There were plans, there were also issues as we don't have a Java based
> mp4 parser so we're relying on the underlying platforms (e.g. QTKit,
> AVFoundation, etc..) to provide that data, which basically means we're
> creating a player at the native level anyways. If you're using the horribly
> outdated FXM format you get the benefit of a Java
> >
> > Deferring to native code absolutely makes sense but I didn't think that
> you needed to create a player to obtain duration, width and height in
> AVFoundation either.
>
> No, but for the lack of a separate interface for metadata retrieval. In
> hindsight there were a number of things that should have been done
> differently :/
>
>
Alright, understood. No offense intended btw.. Thanks for taking the time
to explain!

From david.dehaven at oracle.com  Thu Apr  2 16:27:51 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 2 Apr 2015 09:27:51 -0700
Subject: Media API question regarding metadata retrieval
In-Reply-To: <CAEnqZEUsaXWpMroqM_=iiHwy6CSBRRzHkhoO01mgzj4RgE-G7g@mail.gmail.com>
References: <CAEnqZEWk2QLrDfS4BgWDXSyqpmEmquRin06tt6y0g6DH2-yFYQ@mail.gmail.com>
	<F633153D-1F10-4CAD-BADC-A1AFA85F659F@oracle.com>
	<CAEnqZEV8QF2=FHU=oSJz84sJAyQMeZVb_YjLgSONnuFBjDah3w@mail.gmail.com>
	<A2EF3E98-9F24-4E4C-9669-0359BA6970EE@oracle.com>
	<CAEnqZEUsaXWpMroqM_=iiHwy6CSBRRzHkhoO01mgzj4RgE-G7g@mail.gmail.com>
Message-ID: <CD2A0798-BA8B-455E-A445-0F3295DF5180@oracle.com>


> > > If not is there a specific reason not
> > > to offer this functionality independently of a player?
> >
> > There were plans, there were also issues as we don't have a Java based mp4 parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, etc..) to provide that data, which basically means we're creating a player at the native level anyways. If you're using the horribly outdated FXM format you get the benefit of a Java
> >
> > Deferring to native code absolutely makes sense but I didn't think that you needed to create a player to obtain duration, width and height in AVFoundation either.
> 
> No, but for the lack of a separate interface for metadata retrieval. In hindsight there were a number of things that should have been done differently :/
> 
> 
> Alright, understood. No offense intended btw.. Thanks for taking the time to explain! 

None taken! :) Happy to help when I can.

-DrD-


From james.graham at oracle.com  Thu Apr  2 22:49:56 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Apr 2015 15:49:56 -0700
Subject: Canvas : 2 pixel thick line width
In-Reply-To: <CAAJRru1qEfaTCa9tdk58A9=7fNu8HSPvEmitwWUYc1cskcP3Aw@mail.gmail.com>
References: <CAAJRru014qW3DD-FUyOGvV-t6-bNuKFp6_C1soGiXvd+pHiQag@mail.gmail.com>
	<CAAJRru1qEfaTCa9tdk58A9=7fNu8HSPvEmitwWUYc1cskcP3Aw@mail.gmail.com>
Message-ID: <551DC794.70609@oracle.com>

Hi Damien,

The main problem is that the definition of a stroked path and the 
definition of a filled path are at odds.  If the default stroke width is 
1.0 and the default stroke type is "CENTERED", then the stroke is 
centered on the outline of a path and half of it falls on either side of 
the outline.  For those defaults, if you have the coordinates at pixel 
centers then integer coordinate fills end up with fuzzy sides (and basic 
rectangle fills are the most common operation in any system) even though 
that may help stroked lines and paths.  If you have the coordinates at 
pixel edges then integer fills are nice and crisp and you then only need 
to adjust for stroked shapes.  (Note that on a retina screen with 2x 
pixels you get both crisp fills and strokes either way, so all hail the 
new HiDPI world.  ;)

For non-AA rendering you actually don't get any fuzziness since only 
whole pixels are included or not, but you do have the phenomenon of 
coordinate stability.  If you compute an outline and you are off by just 
a few rounding bits and your coordinates are at the same location as 
your sampling points then your shape shifts.  If the coordinates are 
halfway between the sampling points then a few bits of rounding will not 
affect the shape.

Our default is center of pixel sampling, as it is with most rendering 
systems, so having integer coordinates halfway between them (i.e. at the 
edges of pixels) makes sense for non-AA.

Java2D has a concept called "stroke control" which applies some rounding 
process to all coordinates so as to help them end up creating crisper 
outlines, but it has its drawbacks - particularly in the fact that it 
fights your ability to have a nice round circle or oval since this 
concept of shifting points fights the exact geometry involved in the 
control points of "perfectly round" shapes.

When we were first creating FX we decided that:

- stroke control created some problems that we'd like to avoid even if 
it does provide some security for new programmers

- the vast majority of control styling was shifting to using concentric 
filled backgrounds rather than strokes so the fact that default strokes 
can be fuzzy was a non-issue for the controls team

- we introduced the concepts of inner and outer strokes which play 
better with outlining controls than the typical graphics library's 
default of centered strokes and they have similar needs of where integer 
coordinates should be placed to avoid fuzziness as fills do

- it is time to advance this issue to an exposed one where developers 
will need to be cognizant of our rasterization rules and stroke 
geometries to render correctly.

This should be documented better, though.  That much is true...

			...jim

On 4/1/15 3:14 AM, Damien Dudouit wrote:
> Hello,
>
> I have found the following answer :
>
> http://stackoverflow.com/questions/27846659/how-to-draw-an-1-pixel-line-using-javafx-canvas
>
> *Imagine each pixel as a (small) rectangle (instead of a point). The
> integer coordinates are the boundaries between pixels; so a (horizontal or
> vertical) line with integer coordinates falls "between pixels". This is
> rendered via antialising, approximating half of the line on one pixel and
> half on the other. Moving the line 0.5 pixels left or right moves it to the
> center of the pixel, getting around the issue.*
>
>
> I have done quite a bit of custom controls drawing (canvas) with swing and
> swt and it's quite a shift of approach that plain coordinates to not match
> pixels on display.
>
> In swing/swt, if I want to draw a rectangle from pixel (0,0) to pixel
> (2,2), ie. a square of 3x3 pixels I do :
> gc.drawRectangle(0, 0, 3, 3); // x, y, width, height
>
> In JavaFX I must do :
> gc.strokeRect(0.5, 0.5, 2, 2)
>
> Have a good day,
>
> Damien
>
> 2015-04-01 11:42 GMT+02:00 Damien Dudouit <ddudouit at clio.ch>:
>
>> Hello,
>>
>> I'm using a Canvas to display some content (mostly text with lines also
>> for underline).
>>
>> I've just noticed something that is a big problem for me : with
>> line-width=1 and no scaling, actual line-width on display takes 2 pixels.
>>
>>      Canvas canvas = new Canvas(300, 300);
>>      GraphicsContext gc = canvas.getGraphicsContext2D();
>>      gc.setStroke(Color.BLACK);
>>      gc.setLineWidth(1);
>>      gc.strokeLine(10, 10, 110, 10);
>>
>> I'm running Win7 64bits and I have made the test with Oracle jdk8_40 and
>> jdk7_71 and the result is the same.
>>
>> That 2 pixel thick line is not perfectly black but dark gray.
>> If I do 'gc.setLineWidth(2)', then I get a 2 pixel thick line perfectly
>> black.
>> If I do 'gc.setLineWidth(0.5)', then I get a 2 pixel thick line with a
>> lighter gray.
>>
>> I want to display underline text in the canvas and a 2 pixel thick
>> underline looks bad.
>>
>> Any help would be greatly appreciated.
>>
>> Damien
>>

From james.graham at oracle.com  Thu Apr  2 23:13:51 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 02 Apr 2015 16:13:51 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
Message-ID: <551DCD2F.8080900@oracle.com>

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 <cnewland at chrisnewland.com>
>>> wrote:
>>>
>>>
>>> Hi Jim,
>>>
>>>
>>> Thanks, that makes things much clearer.
>>>
>>>
>>> I was surprised how much was going on under the hood of GraphicsContext
>>>   and hoped it was just magic glue that gave the best of GPU
>>> acceleration where available and immediate-mode-like simple rasterizing
>>> where not.
>>>
>>> I've managed to find an anomaly with GraphicsContext.fillPolygon where
>>> the software pipeline achieves the full 60fps but ES2 can only manage
>>> 30-35fps. It uses lots of overlapping filled triangles so I expect
>>> suffers from the problem you've described.
>>>
>>> SSCCE:
>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch
>>> risnewland/demofx/standalone/Sierpinski.java
>>>
>>> Was full frame rate canvas drawing an expected use case for JavaFX or
>>> would I be better off with Graphics2D?
>>>
>>> Thanks,
>>>
>>>
>>> Chris
>>>
>>>
>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>> Hi Chris,
>>>>
>>>>
>>>>
>>>> drawLine() is a very simple primitive that can be optimized with a
>>>> GPU
>>>> shader.  It either looks like a (potentially rotated) rectangle or a
>>>> rounded rect - and we have optimized shaders for both cases.  A large
>>>>   number of drawLine() calls turns into simply accumulating a large
>>>> vertex list and uploading it to the GPU with an appropriate shader
>>>> which is very fast.
>>>>
>>>> drawPolygon() is a very complex operation that involves things like:
>>>>
>>>> - dealing with line joins between segments that don't exist for
>>>> drawLine() - dealing with only rendering common points of intersection
>>>>   once
>>>>
>>>> To handle all of that complexity we have to involve a rasterizer that
>>>>   takes the entire collection of lines, analyzes the stroke attributes
>>>> and interactions and computes a coverage mask for each pixel in the
>>>> region. We do that in software currently for all pipelines.
>>>>
>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
>>>>   rasterization.
>>>>
>>>> For the SW pipeline, drawLine is a simplified case of drawPolygon and
>>>> so the overhead of lots of calls to drawLine() dominates its
>>>> performance.
>>>>
>>>> I would expect ES2 to blow the SW pipeline out of the water with
>>>> drawLine() performance (as long as there are no additional rendering
>>>> primitives interspersed in the set of lines).
>>>>
>>>> But, both should be on the same footing for the drawPolygon case.
>>>> Does
>>>> the ES2 pipeline compare similarly (hopefully better than) the SW
>>>> pipeline for the polygon case?
>>>>
>>>> One thing I noticed is that we have no optimized case for drawLine()
>>>> on the SW pipeline.  It generates a path containing a single MOVETO
>>>> and LINETO and feeds it to the generalized path rasterizer when it
>>>> could instead compute the rounded/square rectangle and render it more
>>>> directly.  If we added that support then I'd expect the SW pipeline to
>>>> perform the set of drawLine calls faster than drawPolygon as well...
>>>>
>>>> ...jim
>>>>
>>>>
>>>>
>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>>
>>>>>
>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>> investigate thoroughly but when I saw your question I thought I'd
>>>>> better add my findings.
>>>>>
>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>> strokeLine commands as expected:
>>>>>
>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result:
>>>>> 44fps
>>>>>
>>>>>
>>>>>
>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result:
>>>>> 60fps
>>>>>
>>>>>
>>>>>
>>>>> Will see if I can find the root cause as I've got plenty more
>>>>> examples where ES2Pipeline performs horribly on my Mac which should
>>>>> have no problem throwing around a few thousand polys.
>>>>>
>>>>> I realise there's a *lot* of indirection involved in making JavaFX
>>>>> support such a wide range of underlying graphics systems but I do
>>>>> think there's a bug here.
>>>>>
>>>>> Will file a Jira if I can contribute a bit more than "feels slow"
>>>>> ;)
>>>>>
>>>>>
>>>>>
>>>>> 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%20A
>>>>>> ND%2
>>>>>> 0la
>>>>>> bels%20in%20(performance)
>>>>>>
>>>>>> Given that one of the One of the main reasons to use JFX for me
>>>>>> is to be able to develop with one code base for at least OSX and
>>>>>> Windows and
>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>
>>>>>> "JavaFX is a set of graphics and media packages that enables
>>>>>> developers to design, create, test, debug, and deploy rich client
>>>>>> applications that operate consistently across diverse platforms"
>>>>>>
>>>>>> and the fact that this is clearly not the case currently (8u40)
>>>>>> as soon as I do something else than simple forms, I run into
>>>>>> performance/quality problems on the Mac, I am a bit unsure what
>>>>>> to make of all that. Is Mac OSX a second-class citizen as far as
>>>>>> dev resources are concerned?
>>>>>>
>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>> performance that can be tracked?
>>>>>>
>>>>>> I will file an issue with a simple test case and hope for the
>>>>>> best.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>> <cnewland at chrisnewland.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Possibly related:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I can reproduce a massive (90%) performance drop on OSX between
>>>>>>>   drawing a wireframe polygon on a Canvas using a series of
>>>>>>> gc.strokeLine(double x1, double y1, double x2, double y2)
>>>>>>> commands versus using a single gc.strokePolygon(double[]
>>>>>>> xPoints, double[] yPoints, int count) command.
>>>>>>>
>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>
>>>>>>> This is reproducible in a little GitHub JavaFX benchmarking
>>>>>>> project I've
>>>>>>> created: https://github.com/chriswhocodes/DemoFX
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Build with ant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Run with:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> # use strokeLine
>>>>>>> ./run.sh -c 5000 -m line
>>>>>>> result: 60 (sixty) fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> # use strokePolygon
>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>> result: 6 (six) fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM
>>>>>>> /
>>>>>>> Radeon
>>>>>>> 6970M 1024MB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Looking at the code paths in
>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints,
>>>>>>>   true, NGCanvas.STROKE_PATH) which involves significantly more
>>>>>>> work with adding to and flushing a GrowableDataBuffer.
>>>>>>>
>>>>>>> I've not had time to dig any deeper than this but it's surely a
>>>>>>> bug when building a poly manually is 10x faster than using the
>>>>>>> convenience method.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The bad full screen performance is without the arcs. It is
>>>>>>>>> just one call to fillRect, two to strokeOval and one to
>>>>>>>>> fillOval, that's all. I will build a simple test case and
>>>>>>>>> file an issue.
>>>>>>>>>
>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Robert,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please file a Jira issue with a simple test case.  Arcs
>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>> predetermined shader, but it shouldn't be that slow.
>>>>>>>>>> Something else may
>>>>>>>>>> be going on.
>>>>>>>>>>
>>>>>>>>>> Another test might be to replace the arcs with rectangles
>>>>>>>>>> or ellipses and see if the performance changes...
>>>>>>>>>>
>>>>>>>>>> ...jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>> AnimationTimer
>>>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>>>> operations, i.e. fills the screen with a color and then
>>>>>>>>>>>   draws and fills 2-3 circles and I have already
>>>>>>>>>>> observed that each drawing operation I add, results in
>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in
>>>>>>>>>>> addition to the circles, the CPU load goes up to 30-40%
>>>>>>>>>>> on a Mac Book Pro
>>>>>>>>>>> for a Canvas size of 600x600(!).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now I tested the animation in full screen mode (only
>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>> performance known to be very bad on Mac or
>>>>>>>>>>> am I doing something wrong? Are there workarounds for
>>>>>>>>>>> this?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Robert
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Robert Kr????ger
>>>>>>>>> Managing Partner
>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> www.lesspain-software.com
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Robert Kr??ger
>>>>>> Managing Partner
>>>>>> Lesspain GmbH & Co. KG
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> www.lesspain-software.com
>>>
>>>
>>
>
>

From peter.penzov at gmail.com  Fri Apr  3 13:46:48 2015
From: peter.penzov at gmail.com (Peter Penzov)
Date: Fri, 3 Apr 2015 16:46:48 +0300
Subject: Change BarChart Legend color
Message-ID: <CAJm-gituTpyMGWkt4aXBdjmEa2Hw_pBUT2Uds=ovZbuHcfGVsg@mail.gmail.com>

Hi All,
   I have a question about changing dynamically the color of the BarChart.
I'm using this code to change the chart Label for now successfully:

Legend legend = (Legend) schart.lookup(".chart-legend");
            Legend.LegendItem li1 = new Legend.LegendItem("Over 8", new
Rectangle(10, 4, Color.NAVY));
            Legend.LegendItem li2 = new Legend.LegendItem("Over 5 up to 8",
new Rectangle(10, 4, Color.FIREBRICK));
            Legend.LegendItem li3 = new Legend.LegendItem("Below 5", new
Rectangle(10, 4, Color.ORANGE));
            legend.getItems().setAll(li1, li2, li3);

But Label is from the internal package com.sun.javafx.charts.Legend and I
may have problems into the next JVM versions.

Is there other way to change BarChart label colors. Please refer to this
link for more information:

http://stackoverflow.com/questions/29121687/change-color-in-barchart-legend

Also are there any plans to make Label public package?

BR,
Peter

From vadim.pakhnushev at oracle.com  Fri Apr  3 14:37:59 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 03 Apr 2015 17:37:59 +0300
Subject: In(Sanity) Testing Mondays
Message-ID: <551EA5C7.5060402@oracle.com>

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PST until 1pm 
PST.

Happy testing!

Thanks,
Vadim

From tbee at tbee.org  Fri Apr  3 17:48:15 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Fri, 03 Apr 2015 19:48:15 +0200
Subject: Debugging CSS
Message-ID: <551ED25F.4070902@tbee.org>

I'm pushing the envelope a bit -I think- concerning the use of CSS. I have setup a control (gauge) in such a way that, depending on the position of the needle, certain CSS classes are added or removed from the control. For example a "errorSegment-active" class if the value comes into the 90-100 value in a 0-100 gauge. In this class a CSS variable -fx-error-indicator-visibility is set to "visible" and that again shows some kind of indicator on the gauge. Works great.

What is strange is when this class is assigned to the control, a totally unrelated node (the value in the needle) suddenly moves out of position. I do not understand this, because the CSS only involves colors and visibility, never any transformation.
https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css

Is there any way to debug what CSS settings are applied to nodes? I really would like to find out what causes that node to move.

Tom

From tbee at tbee.org  Fri Apr  3 18:13:05 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Fri, 03 Apr 2015 20:13:05 +0200
Subject: Debugging CSS
In-Reply-To: <551ED25F.4070902@tbee.org>
References: <551ED25F.4070902@tbee.org>
Message-ID: <551ED831.4000904@tbee.org>

One addition: the move happens if, for example, "segment0-active" is added to the skinnable. Even if that class is empty or even not defined in the CSS.

Tom

On 3-4-2015 19:48, Tom Eugelink wrote:
> I'm pushing the envelope a bit -I think- concerning the use of CSS. I have setup a control (gauge) in such a way that, depending on the position of the needle, certain CSS classes are added or removed from the control. For example a "errorSegment-active" class if the value comes into the 90-100 value in a 0-100 gauge. In this class a CSS variable -fx-error-indicator-visibility is set to "visible" and that again shows some kind of indicator on the gauge. Works great.
>
> What is strange is when this class is assigned to the control, a totally unrelated node (the value in the needle) suddenly moves out of position. I do not understand this, because the CSS only involves colors and visibility, never any transformation.
> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css
>
> Is there any way to debug what CSS settings are applied to nodes? I really would like to find out what causes that node to move.
>
> Tom


From david.grieve at oracle.com  Fri Apr  3 20:19:34 2015
From: david.grieve at oracle.com (David Grieve)
Date: Fri, 03 Apr 2015 16:19:34 -0400
Subject: Debugging CSS
In-Reply-To: <551ED831.4000904@tbee.org>
References: <551ED25F.4070902@tbee.org> <551ED831.4000904@tbee.org>
Message-ID: <551EF5D6.8090107@oracle.com>

When you add or remove style-classes, CSS for the node (and all its 
children) is totally re-calculated. This means that cached data for that 
node is tossed out and the node is styled from scratch, as if it were 
just added to the scene-graph.

You are much better off using pseudo-class state for what you are trying 
to do. Changes in pseudo-class state just causes evaluation of what 
styles are applied in that state, which is relatively low overhead 
compared to re-calculating styles.

To debug, you should try using Scenic View 
(http://fxexperience.com/scenic-view/)

You can also use the Node API Map<StyleableProperty<?>,List<Style>> 
impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap). Note 
that this is deprecated API

On 4/3/15 2:13 PM, Tom Eugelink wrote:
> One addition: the move happens if, for example, "segment0-active" is 
> added to the skinnable. Even if that class is empty or even not 
> defined in the CSS.
>
> Tom
>
> On 3-4-2015 19:48, Tom Eugelink wrote:
>> I'm pushing the envelope a bit -I think- concerning the use of CSS. I 
>> have setup a control (gauge) in such a way that, depending on the 
>> position of the needle, certain CSS classes are added or removed from 
>> the control. For example a "errorSegment-active" class if the value 
>> comes into the 90-100 value in a 0-100 gauge. In this class a CSS 
>> variable -fx-error-indicator-visibility is set to "visible" and that 
>> again shows some kind of indicator on the gauge. Works great.
>>
>> What is strange is when this class is assigned to the control, a 
>> totally unrelated node (the value in the needle) suddenly moves out 
>> of position. I do not understand this, because the CSS only involves 
>> colors and visibility, never any transformation.
>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 
>>
>>
>> Is there any way to debug what CSS settings are applied to nodes? I 
>> really would like to find out what causes that node to move.
>>
>> Tom
>


From swpalmer at gmail.com  Fri Apr  3 20:39:15 2015
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 3 Apr 2015 16:39:15 -0400
Subject: Debugging CSS
In-Reply-To: <551EF5D6.8090107@oracle.com>
References: <551ED25F.4070902@tbee.org> <551ED831.4000904@tbee.org>
	<551EF5D6.8090107@oracle.com>
Message-ID: <CAL3e5iFMDXqfvN64bYZHs+GE88AQDYRVbgKO9UJoTaBGKKP6aQ@mail.gmail.com>

How exactly can you use pseudo-class state for this sort of change?

I have a similar requirement in my own app.  It always did feel a little
'heavy' when I added and removed style-classes, but it still seemed like
the best way to trigger visual changes on my nodes.
Though I guess one benefit is that by frequently changing the style-classes
in a node I discovered leaks in ProgressBar that were subsquently exposed
(RT-40384).

Scott


On Fri, Apr 3, 2015 at 4:19 PM, David Grieve <david.grieve at oracle.com>
wrote:

> When you add or remove style-classes, CSS for the node (and all its
> children) is totally re-calculated. This means that cached data for that
> node is tossed out and the node is styled from scratch, as if it were just
> added to the scene-graph.
>
> You are much better off using pseudo-class state for what you are trying
> to do. Changes in pseudo-class state just causes evaluation of what styles
> are applied in that state, which is relatively low overhead compared to
> re-calculating styles.
>
> To debug, you should try using Scenic View (http://fxexperience.com/
> scenic-view/)
>
> You can also use the Node API Map<StyleableProperty<?>,List<Style>>
> impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap). Note
> that this is deprecated API
>
>
> On 4/3/15 2:13 PM, Tom Eugelink wrote:
>
>> One addition: the move happens if, for example, "segment0-active" is
>> added to the skinnable. Even if that class is empty or even not defined in
>> the CSS.
>>
>> Tom
>>
>> On 3-4-2015 19:48, Tom Eugelink wrote:
>>
>>> I'm pushing the envelope a bit -I think- concerning the use of CSS. I
>>> have setup a control (gauge) in such a way that, depending on the position
>>> of the needle, certain CSS classes are added or removed from the control.
>>> For example a "errorSegment-active" class if the value comes into the
>>> 90-100 value in a 0-100 gauge. In this class a CSS variable
>>> -fx-error-indicator-visibility is set to "visible" and that again shows
>>> some kind of indicator on the gauge. Works great.
>>>
>>> What is strange is when this class is assigned to the control, a totally
>>> unrelated node (the value in the needle) suddenly moves out of position. I
>>> do not understand this, because the CSS only involves colors and
>>> visibility, never any transformation.
>>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/
>>> main/resources/jfxtras/labs/internal/scene/control/gauge/
>>> linear/SimpleMetroArcGauge.css
>>>
>>> Is there any way to debug what CSS settings are applied to nodes? I
>>> really would like to find out what causes that node to move.
>>>
>>> Tom
>>>
>>
>>
>

From tbee at tbee.org  Sat Apr  4 06:14:31 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Sat, 04 Apr 2015 08:14:31 +0200
Subject: Debugging CSS
In-Reply-To: <551EF5D6.8090107@oracle.com>
References: <551ED25F.4070902@tbee.org> <551ED831.4000904@tbee.org>
	<551EF5D6.8090107@oracle.com>
Message-ID: <551F8147.3050205@tbee.org>

After loads of trail and error I pinned it down to the fact that scaling of the node in question was not taking into account when positioning it; it is centered and I use its width to do that, but it was the width-before-scaling. So it was a miracle it was in the right place at all. What really would be needed here (and I think anyone who has done HTML with CSS will agree) is a which-property-is-set-by-which-CSS-class-and-file, like the debug view in browsers. Does the CSS engine keep track of this information?

Tom


On 3-4-2015 22:19, David Grieve wrote:
> When you add or remove style-classes, CSS for the node (and all its children) is totally re-calculated. This means that cached data for that node is tossed out and the node is styled from scratch, as if it were just added to the scene-graph.
>
> You are much better off using pseudo-class state for what you are trying to do. Changes in pseudo-class state just causes evaluation of what styles are applied in that state, which is relatively low overhead compared to re-calculating styles.
>
> To debug, you should try using Scenic View (http://fxexperience.com/scenic-view/)
>
> You can also use the Node API Map<StyleableProperty<?>,List<Style>> impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap). Note that this is deprecated API
>
> On 4/3/15 2:13 PM, Tom Eugelink wrote:
>> One addition: the move happens if, for example, "segment0-active" is added to the skinnable. Even if that class is empty or even not defined in the CSS.
>>
>> Tom
>>
>> On 3-4-2015 19:48, Tom Eugelink wrote:
>>> I'm pushing the envelope a bit -I think- concerning the use of CSS. I have setup a control (gauge) in such a way that, depending on the position of the needle, certain CSS classes are added or removed from the control. For example a "errorSegment-active" class if the value comes into the 90-100 value in a 0-100 gauge. In this class a CSS variable -fx-error-indicator-visibility is set to "visible" and that again shows some kind of indicator on the gauge. Works great.
>>>
>>> What is strange is when this class is assigned to the control, a totally unrelated node (the value in the needle) suddenly moves out of position. I do not understand this, because the CSS only involves colors and visibility, never any transformation.
>>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css
>>>
>>> Is there any way to debug what CSS settings are applied to nodes? I really would like to find out what causes that node to move.
>>>
>>> Tom
>>
>


From cnewland at chrisnewland.com  Sat Apr  4 20:31:29 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Sat, 4 Apr 2015 21:31:29 +0100
Subject: Canvas performance on Mac OS
Message-ID: <658cf2b38d51f58aeea334cfa830f00e.squirrel@excalibur.xssl.net>

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
>>>> <cnewland at chrisnewland.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> Hi Jim,
>>>>
>>>>
>>>>
>>>> Thanks, that makes things much clearer.
>>>>
>>>>
>>>>
>>>> I was surprised how much was going on under the hood of
>>>> GraphicsContext
>>>> and hoped it was just magic glue that gave the best of GPU
>>>> acceleration where available and immediate-mode-like simple
>>>> rasterizing where not.
>>>>
>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>> where the software pipeline achieves the full 60fps but ES2 can only
>>>> manage 30-35fps. It uses lots of overlapping filled triangles so I
>>>> expect suffers from the problem you've described.
>>>>
>>>> SSCCE:
>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/co
>>>> m/ch risnewland/demofx/standalone/Sierpinski.java
>>>>
>>>> Was full frame rate canvas drawing an expected use case for JavaFX
>>>> or would I be better off with Graphics2D?
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> drawLine() is a very simple primitive that can be optimized with
>>>>> a GPU
>>>>> shader.  It either looks like a (potentially rotated) rectangle or
>>>>> a rounded rect - and we have optimized shaders for both cases.  A
>>>>> large number of drawLine() calls turns into simply accumulating a
>>>>> large vertex list and uploading it to the GPU with an appropriate
>>>>> shader which is very fast.
>>>>>
>>>>> drawPolygon() is a very complex operation that involves things
>>>>> like:
>>>>>
>>>>>
>>>>> - dealing with line joins between segments that don't exist for
>>>>> drawLine() - dealing with only rendering common points of
>>>>> intersection once
>>>>>
>>>>> To handle all of that complexity we have to involve a rasterizer
>>>>> 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
>>>>>>> %20A
>>>>>>> ND%2
>>>>>>> 0la
>>>>>>> bels%20in%20(performance)
>>>>>>>
>>>>>>> Given that one of the One of the main reasons to use JFX for
>>>>>>> me is to be able to develop with one code base for at least
>>>>>>> OSX and
>>>>>>> Windows and
>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>
>>>>>>> "JavaFX is a set of graphics and media packages that enables
>>>>>>> developers to design, create, test, debug, and deploy rich
>>>>>>> client applications that operate consistently across diverse
>>>>>>> platforms"
>>>>>>>
>>>>>>> and the fact that this is clearly not the case currently
>>>>>>> (8u40)
>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>> performance/quality problems on the Mac, I am a bit unsure
>>>>>>> what to make of all that. Is Mac OSX a second-class citizen as
>>>>>>> far as dev resources are concerned?
>>>>>>>
>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>> performance that can be tracked?
>>>>>>>
>>>>>>> I will file an issue with a simple test case and hope for the
>>>>>>>  best.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>> <cnewland at chrisnewland.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Possibly related:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>> double y2) commands versus using a single
>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>> count) command.
>>>>>>>>
>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>
>>>>>>>> This is reproducible in a little GitHub JavaFX benchmarking
>>>>>>>>  project I've created:
>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Build with ant
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Run with:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> # use strokeLine
>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>> result: 60 (sixty) fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> # use strokePolygon
>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>> result: 6 (six) fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB
>>>>>>>> RAM
>>>>>>>> /
>>>>>>>> Radeon
>>>>>>>> 6970M 1024MB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Looking at the code paths in
>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>> GrowableDataBuffer.
>>>>>>>>
>>>>>>>>
>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>> than using the convenience method.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The bad full screen performance is without the arcs. It
>>>>>>>>>> is just one call to fillRect, two to strokeOval and one
>>>>>>>>>> to fillOval, that's all. I will build a simple test case
>>>>>>>>>> and file an issue.
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>> Arcs
>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>> predetermined shader, but it shouldn't be that slow.
>>>>>>>>>>> Something else may
>>>>>>>>>>> be going on.
>>>>>>>>>>>
>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>> changes...
>>>>>>>>>>>
>>>>>>>>>>> ...jim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>> AnimationTimer
>>>>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>>>>>  operations, i.e. fills the screen with a color and
>>>>>>>>>>>> then draws and fills 2-3 circles and I have already
>>>>>>>>>>>> observed that each drawing operation I add, results
>>>>>>>>>>>> in significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>> in addition to the circles, the CPU load goes up to
>>>>>>>>>>>> 30-40%
>>>>>>>>>>>> on a Mac Book Pro for a Canvas size of 600x600(!).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>> (only
>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>> this?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Robert
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Robert Kr????ger
>>>>>>>>>> Managing Partner
>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> www.lesspain-software.com
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Robert Kr??ger
>>>>>>> Managing Partner
>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> www.lesspain-software.com
>>>>
>>>>
>>>
>>
>>
>



From krueger at lesspain.de  Sun Apr  5 07:04:29 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Sun, 5 Apr 2015 09:04:29 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <658cf2b38d51f58aeea334cfa830f00e.squirrel@excalibur.xssl.net>
References: <658cf2b38d51f58aeea334cfa830f00e.squirrel@excalibur.xssl.net>
Message-ID: <CAEnqZEWrbsGScBbZ_coHjRvs0iMrkTn2d4xXT70bjOSwpORMyA@mail.gmail.com>

Hi,

On Sat, Apr 4, 2015 at 10:31 PM, Chris Newland <cnewland at chrisnewland.com>
wrote:

> Hi Jim,
>
>
>
-snip


> 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 think there is also a general problem not related to 2d drawing at least
on 10.10.2. For RT-40377 I created a simple node-based alternative which is
animating _one_ circle and in full-screen mode I get 25-35 fps on my retina
MBP. Maybe it's unrelated but maybe there is an additional throttle
somewhere also affecting your case.


> I would have expected the hardware I've tested on to eat 2500 triangles at
> 60fps for breakfast even with no GPU acceleration.
>
>
Yes, for my case with one circle I would have expected almost no CPU but I
still get 15% which I find quite a bit for rendering one circle 30
times/sec.


> I'm going to knock up a version of this code that uses Graphics2D for
> comparison.
>
>
If you do that, please also include numbers for running that code with
Apple Java 6 as well, because there are quite a few people still saying
that Apple's Java 6 outperforms Oracle's Java by a lot in 2D Graphics.


> Cheers,
>
> Chris
>
>
I don't know what else to do but to lobby here and invest some work in Jira
issues with reproducible test cases. There is a huge performance problem on
the Mac (I have to admit, I have no Windows machine to compare myself) with
the potential to drive companies like ours, which is seriously
considering/testing the technology for our product development, away from
the technology. I would also hope that other people who have encountered
this like the Ultramixer guys don't give up on this and keep posting
qualified information, making the case for this and supporting the Oracle
team by reproducible benchmarks/test cases.

Cheers,

Robert

From tbee at tbee.org  Sun Apr  5 07:56:46 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Sun, 05 Apr 2015 09:56:46 +0200
Subject: Debugging CSS
In-Reply-To: <551F8147.3050205@tbee.org>
References: <551ED25F.4070902@tbee.org>
	<551ED831.4000904@tbee.org>	<551EF5D6.8090107@oracle.com>
	<551F8147.3050205@tbee.org>
Message-ID: <5520EABE.10709@tbee.org>

I have another interesting behavior involving CSS. The gauge has a text representation of the value of the needle, which can be formatted using DecimalFormat. The format string can be set with a styleable property.

In the example this property is set, via setStyle(), to something with a unit postfix, e.g. "##0.0W" so the gauge will show watts. This works. But as soon as totally unrelated classes are removed from the gauge, the styleable property reverts to its initial value, but the style string is unchanged!

This behavior is introduced in 8u20, in 8u00 it works as intended.

Tom

On 4-4-2015 08:14, Tom Eugelink wrote:
> After loads of trail and error I pinned it down to the fact that scaling of the node in question was not taking into account when positioning it; it is centered and I use its width to do that, but it was the width-before-scaling. So it was a miracle it was in the right place at all. What really would be needed here (and I think anyone who has done HTML with CSS will agree) is a which-property-is-set-by-which-CSS-class-and-file, like the debug view in browsers. Does the CSS engine keep track of this information?
>
> Tom
>
>
> On 3-4-2015 22:19, David Grieve wrote:
>> When you add or remove style-classes, CSS for the node (and all its children) is totally re-calculated. This means that cached data for that node is tossed out and the node is styled from scratch, as if it were just added to the scene-graph.
>>
>> You are much better off using pseudo-class state for what you are trying to do. Changes in pseudo-class state just causes evaluation of what styles are applied in that state, which is relatively low overhead compared to re-calculating styles.
>>
>> To debug, you should try using Scenic View (http://fxexperience.com/scenic-view/)
>>
>> You can also use the Node API Map<StyleableProperty<?>,List<Style>> impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap). Note that this is deprecated API
>>
>> On 4/3/15 2:13 PM, Tom Eugelink wrote:
>>> One addition: the move happens if, for example, "segment0-active" is added to the skinnable. Even if that class is empty or even not defined in the CSS.
>>>
>>> Tom
>>>
>>> On 3-4-2015 19:48, Tom Eugelink wrote:
>>>> I'm pushing the envelope a bit -I think- concerning the use of CSS. I have setup a control (gauge) in such a way that, depending on the position of the needle, certain CSS classes are added or removed from the control. For example a "errorSegment-active" class if the value comes into the 90-100 value in a 0-100 gauge. In this class a CSS variable -fx-error-indicator-visibility is set to "visible" and that again shows some kind of indicator on the gauge. Works great.
>>>>
>>>> What is strange is when this class is assigned to the control, a totally unrelated node (the value in the needle) suddenly moves out of position. I do not understand this, because the CSS only involves colors and visibility, never any transformation.
>>>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css
>>>>
>>>> Is there any way to debug what CSS settings are applied to nodes? I really would like to find out what causes that node to move.
>>>>
>>>> Tom
>>>
>>
>


From david.grieve at oracle.com  Sun Apr  5 22:58:30 2015
From: david.grieve at oracle.com (David Grieve)
Date: Sun, 05 Apr 2015 18:58:30 -0400
Subject: Debugging CSS
In-Reply-To: <5520EABE.10709@tbee.org>
References: <551ED25F.4070902@tbee.org>	<551ED831.4000904@tbee.org>	<551EF5D6.8090107@oracle.com>	<551F8147.3050205@tbee.org>
	<5520EABE.10709@tbee.org>
Message-ID: <5521BE16.3070400@oracle.com>



On 4/5/15 3:56 AM, Tom Eugelink wrote:
> I have another interesting behavior involving CSS. The gauge has a 
> text representation of the value of the needle, which can be formatted 
> using DecimalFormat. The format string can be set with a styleable 
> property.
>
> In the example this property is set, via setStyle(), to something with 
> a unit postfix, e.g. "##0.0W" so the gauge will show watts. This 
> works. But as soon as totally unrelated classes are removed from the 
> gauge, the styleable property reverts to its initial value, but the 
> style string is unchanged!
>
> This behavior is introduced in 8u20, in 8u00 it works as intended.
And in 8u40?
>
> Tom
>
> On 4-4-2015 08:14, Tom Eugelink wrote:
>> After loads of trail and error I pinned it down to the fact that 
>> scaling of the node in question was not taking into account when 
>> positioning it; it is centered and I use its width to do that, but it 
>> was the width-before-scaling. So it was a miracle it was in the right 
>> place at all. What really would be needed here (and I think anyone 
>> who has done HTML with CSS will agree) is a 
>> which-property-is-set-by-which-CSS-class-and-file, like the debug 
>> view in browsers. Does the CSS engine keep track of this information?
>>
When it comes time to pick the style for a property, the CSS engine does 
not know which CSS file a property came from. The APIs mentioned below 
are all you have when it comes to finding what styles apply to a node. 
These methods are, in fact, the methods that Scene Builder uses for its 
CSS analyzer.
>> Tom
>>
>>
>> On 3-4-2015 22:19, David Grieve wrote:
>>> When you add or remove style-classes, CSS for the node (and all its 
>>> children) is totally re-calculated. This means that cached data for 
>>> that node is tossed out and the node is styled from scratch, as if 
>>> it were just added to the scene-graph.
>>>
>>> You are much better off using pseudo-class state for what you are 
>>> trying to do. Changes in pseudo-class state just causes evaluation 
>>> of what styles are applied in that state, which is relatively low 
>>> overhead compared to re-calculating styles.
>>>
>>> To debug, you should try using Scenic View 
>>> (http://fxexperience.com/scenic-view/)
>>>
>>> You can also use the Node API Map<StyleableProperty<?>,List<Style>> 
>>> impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap). 
>>> Note that this is deprecated API
>>>
>>> On 4/3/15 2:13 PM, Tom Eugelink wrote:
>>>> One addition: the move happens if, for example, "segment0-active" 
>>>> is added to the skinnable. Even if that class is empty or even not 
>>>> defined in the CSS.
>>>>
>>>> Tom
>>>>
>>>> On 3-4-2015 19:48, Tom Eugelink wrote:
>>>>> I'm pushing the envelope a bit -I think- concerning the use of 
>>>>> CSS. I have setup a control (gauge) in such a way that, depending 
>>>>> on the position of the needle, certain CSS classes are added or 
>>>>> removed from the control. For example a "errorSegment-active" 
>>>>> class if the value comes into the 90-100 value in a 0-100 gauge. 
>>>>> In this class a CSS variable -fx-error-indicator-visibility is set 
>>>>> to "visible" and that again shows some kind of indicator on the 
>>>>> gauge. Works great.
>>>>>
>>>>> What is strange is when this class is assigned to the control, a 
>>>>> totally unrelated node (the value in the needle) suddenly moves 
>>>>> out of position. I do not understand this, because the CSS only 
>>>>> involves colors and visibility, never any transformation.
>>>>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 
>>>>>
>>>>>
>>>>> Is there any way to debug what CSS settings are applied to nodes? 
>>>>> I really would like to find out what causes that node to move.
>>>>>
>>>>> Tom
>>>>
>>>
>>
>


From tbee at tbee.org  Mon Apr  6 07:31:18 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Mon, 06 Apr 2015 09:31:18 +0200
Subject: Debugging CSS
In-Reply-To: <5521BE16.3070400@oracle.com>
References: <551ED25F.4070902@tbee.org>	<551ED831.4000904@tbee.org>	<551EF5D6.8090107@oracle.com>	<551F8147.3050205@tbee.org>	<5520EABE.10709@tbee.org>
	<5521BE16.3070400@oracle.com>
Message-ID: <55223646.1050105@tbee.org>

On 6-4-2015 00:58, David Grieve wrote:
>
>
> On 4/5/15 3:56 AM, Tom Eugelink wrote:
>> I have another interesting behavior involving CSS. The gauge has a text representation of the value of the needle, which can be formatted using DecimalFormat. The format string can be set with a styleable property.
>>
>> In the example this property is set, via setStyle(), to something with a unit postfix, e.g. "##0.0W" so the gauge will show watts. This works. But as soon as totally unrelated classes are removed from the gauge, the styleable property reverts to its initial value, but the style string is unchanged!
>>
>> This behavior is introduced in 8u20, in 8u00 it works as intended.
> And in 8u40?

The behavior is still present in 8u40. It is easy to see; checkout JFXtras labs from github, open the project in you favorite IDE, and start the SimpleMetroArcGaugeTrail1 class. It's the gauge with the "W" in the text, at first :-)

Tom

From david.grieve at oracle.com  Mon Apr  6 14:25:41 2015
From: david.grieve at oracle.com (David Grieve)
Date: Mon, 06 Apr 2015 10:25:41 -0400
Subject: Debugging CSS
In-Reply-To: <55223646.1050105@tbee.org>
References: <551ED25F.4070902@tbee.org>	<551ED831.4000904@tbee.org>	<551EF5D6.8090107@oracle.com>	<551F8147.3050205@tbee.org>	<5520EABE.10709@tbee.org>	<5521BE16.3070400@oracle.com>
	<55223646.1050105@tbee.org>
Message-ID: <55229765.7040607@oracle.com>

You should file an issue in jira for this.

On 4/6/15 3:31 AM, Tom Eugelink wrote:
> On 6-4-2015 00:58, David Grieve wrote:
>>
>>
>> On 4/5/15 3:56 AM, Tom Eugelink wrote:
>>> I have another interesting behavior involving CSS. The gauge has a 
>>> text representation of the value of the needle, which can be 
>>> formatted using DecimalFormat. The format string can be set with a 
>>> styleable property.
>>>
>>> In the example this property is set, via setStyle(), to something 
>>> with a unit postfix, e.g. "##0.0W" so the gauge will show watts. 
>>> This works. But as soon as totally unrelated classes are removed 
>>> from the gauge, the styleable property reverts to its initial value, 
>>> but the style string is unchanged!
>>>
>>> This behavior is introduced in 8u20, in 8u00 it works as intended.
>> And in 8u40?
>
> The behavior is still present in 8u40. It is easy to see; checkout 
> JFXtras labs from github, open the project in you favorite IDE, and 
> start the SimpleMetroArcGaugeTrail1 class. It's the gauge with the "W" 
> in the text, at first :-)
>
> Tom


From tbee at tbee.org  Mon Apr  6 15:33:32 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Mon, 06 Apr 2015 17:33:32 +0200
Subject: Debugging CSS
In-Reply-To: <55229765.7040607@oracle.com>
References: <551ED25F.4070902@tbee.org>	<551ED831.4000904@tbee.org>	<551EF5D6.8090107@oracle.com>	<551F8147.3050205@tbee.org>	<5520EABE.10709@tbee.org>	<5521BE16.3070400@oracle.com>	<55223646.1050105@tbee.org>
	<55229765.7040607@oracle.com>
Message-ID: <5522A74C.1080907@tbee.org>

https://javafx-jira.kenai.com/browse/RT-40437


On 6-4-2015 16:25, David Grieve wrote:
> You should file an issue in jira for this.
>
> On 4/6/15 3:31 AM, Tom Eugelink wrote:
>> On 6-4-2015 00:58, David Grieve wrote:
>>>
>>>
>>> On 4/5/15 3:56 AM, Tom Eugelink wrote:
>>>> I have another interesting behavior involving CSS. The gauge has a text representation of the value of the needle, which can be formatted using DecimalFormat. The format string can be set with a styleable property.
>>>>
>>>> In the example this property is set, via setStyle(), to something with a unit postfix, e.g. "##0.0W" so the gauge will show watts. This works. But as soon as totally unrelated classes are removed from the gauge, the styleable property reverts to its initial value, but the style string is unchanged!
>>>>
>>>> This behavior is introduced in 8u20, in 8u00 it works as intended.
>>> And in 8u40?
>>
>> The behavior is still present in 8u40. It is easy to see; checkout JFXtras labs from github, open the project in you favorite IDE, and start the SimpleMetroArcGaugeTrail1 class. It's the gauge with the "W" in the text, at first :-)
>>
>> Tom
>


From kevin.rushforth at oracle.com  Mon Apr  6 20:07:08 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 06 Apr 2015 13:07:08 -0700
Subject: 9-dev and 8u-dev unlocked following this week's sanity testing <eom>
Message-ID: <5522E76C.1030809@oracle.com>



From morris.meyer at oracle.com  Mon Apr  6 21:01:02 2015
From: morris.meyer at oracle.com (Morris Meyer)
Date: Mon, 06 Apr 2015 17:01:02 -0400
Subject: [8u60] Request for review: RT-40385: [Mac] NPE in window close unit
	tests
Message-ID: <5522F40E.1040300@oracle.com>

David and Kevin,

Please review my fix for the recent regression caused by my fix for 
RT-39813.  Both changes crop up in the systemTests and are necessary to 
adjust for the close sequence timing change introduced in RT-39813.

Tested using:

gradle -PFULL_TEST=true :systemTests:test

Thanks much.

         --morris

WEBREV - http://cr.openjdk.java.net/~morris/RT-40385.01/
JIRA - https://javafx-jira.kenai.com/browse/RT-40385

From kevin.rushforth at oracle.com  Mon Apr  6 21:29:03 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 06 Apr 2015 14:29:03 -0700
Subject: [8u60] Request for review: RT-40385: [Mac] NPE in window close
	unit tests
In-Reply-To: <5522F40E.1040300@oracle.com>
References: <5522F40E.1040300@oracle.com>
Message-ID: <5522FA9F.9000303@oracle.com>

As a reminder, bug fixes should go into 9-dev before (or at the same 
time) as into 8u-dev.

-- Kevin


Morris Meyer wrote:
> David and Kevin,
>
> Please review my fix for the recent regression caused by my fix for 
> RT-39813.  Both changes crop up in the systemTests and are necessary 
> to adjust for the close sequence timing change introduced in RT-39813.
>
> Tested using:
>
> gradle -PFULL_TEST=true :systemTests:test
>
> Thanks much.
>
>         --morris
>
> WEBREV - http://cr.openjdk.java.net/~morris/RT-40385.01/
> JIRA - https://javafx-jira.kenai.com/browse/RT-40385

From johan at lodgon.com  Tue Apr  7 18:16:45 2015
From: johan at lodgon.com (Johan Vos)
Date: Tue, 7 Apr 2015 20:16:45 +0200
Subject: prism monocle
Message-ID: <CABek58=0XUcL+VqRbRodwbT+vC6OK5jOAB5nKWUqqJ9f0=Si5g@mail.gmail.com>

Hi,

I'm a bit confused on the directory structure for the prism-monocle
implementation. I created https://javafx-jira.kenai.com/browse/RT-40467 for
this.
There are calls to getNativeWindowType being made in monocle/eglUtils.c but
the implementation is only in the eglfb subdirectory. The eglUtils.c file
itself is both in monocle as well as in eglfb.
For the android implementation, I duplicated the wrapped_egl.c file in the
monocle directory as well, but I don't think this is how it should be?

- Johan

From james.graham at oracle.com  Tue Apr  7 23:16:28 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 07 Apr 2015 16:16:28 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <551DCD2F.8080900@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>	<5515C483.9030901@oracle.com>	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>	<55199E52.9090503@oracle.com>	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com>
Message-ID: <5524654C.2060500@oracle.com>

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 <cnewland at chrisnewland.com>
>>>> wrote:
>>>>
>>>>
>>>> Hi Jim,
>>>>
>>>>
>>>> Thanks, that makes things much clearer.
>>>>
>>>>
>>>> I was surprised how much was going on under the hood of GraphicsContext
>>>>   and hoped it was just magic glue that gave the best of GPU
>>>> acceleration where available and immediate-mode-like simple rasterizing
>>>> where not.
>>>>
>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon where
>>>> the software pipeline achieves the full 60fps but ES2 can only manage
>>>> 30-35fps. It uses lots of overlapping filled triangles so I expect
>>>> suffers from the problem you've described.
>>>>
>>>> SSCCE:
>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch
>>>>
>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>
>>>> Was full frame rate canvas drawing an expected use case for JavaFX or
>>>> would I be better off with Graphics2D?
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Chris
>>>>
>>>>
>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>> Hi Chris,
>>>>>
>>>>>
>>>>>
>>>>> drawLine() is a very simple primitive that can be optimized with a
>>>>> GPU
>>>>> shader.  It either looks like a (potentially rotated) rectangle or a
>>>>> rounded rect - and we have optimized shaders for both cases.  A large
>>>>>   number of drawLine() calls turns into simply accumulating a large
>>>>> vertex list and uploading it to the GPU with an appropriate shader
>>>>> which is very fast.
>>>>>
>>>>> drawPolygon() is a very complex operation that involves things like:
>>>>>
>>>>> - dealing with line joins between segments that don't exist for
>>>>> drawLine() - dealing with only rendering common points of intersection
>>>>>   once
>>>>>
>>>>> To handle all of that complexity we have to involve a rasterizer that
>>>>>   takes the entire collection of lines, analyzes the stroke attributes
>>>>> and interactions and computes a coverage mask for each pixel in the
>>>>> region. We do that in software currently for all pipelines.
>>>>>
>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
>>>>>   rasterization.
>>>>>
>>>>> For the SW pipeline, drawLine is a simplified case of drawPolygon and
>>>>> so the overhead of lots of calls to drawLine() dominates its
>>>>> performance.
>>>>>
>>>>> I would expect ES2 to blow the SW pipeline out of the water with
>>>>> drawLine() performance (as long as there are no additional rendering
>>>>> primitives interspersed in the set of lines).
>>>>>
>>>>> But, both should be on the same footing for the drawPolygon case.
>>>>> Does
>>>>> the ES2 pipeline compare similarly (hopefully better than) the SW
>>>>> pipeline for the polygon case?
>>>>>
>>>>> One thing I noticed is that we have no optimized case for drawLine()
>>>>> on the SW pipeline.  It generates a path containing a single MOVETO
>>>>> and LINETO and feeds it to the generalized path rasterizer when it
>>>>> could instead compute the rounded/square rectangle and render it more
>>>>> directly.  If we added that support then I'd expect the SW pipeline to
>>>>> perform the set of drawLine calls faster than drawPolygon as well...
>>>>>
>>>>> ...jim
>>>>>
>>>>>
>>>>>
>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>
>>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>> investigate thoroughly but when I saw your question I thought I'd
>>>>>> better add my findings.
>>>>>>
>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>> strokeLine commands as expected:
>>>>>>
>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result:
>>>>>> 44fps
>>>>>>
>>>>>>
>>>>>>
>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result:
>>>>>> 60fps
>>>>>>
>>>>>>
>>>>>>
>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>> examples where ES2Pipeline performs horribly on my Mac which should
>>>>>> have no problem throwing around a few thousand polys.
>>>>>>
>>>>>> I realise there's a *lot* of indirection involved in making JavaFX
>>>>>> support such a wide range of underlying graphics systems but I do
>>>>>> think there's a bug here.
>>>>>>
>>>>>> Will file a Jira if I can contribute a bit more than "feels slow"
>>>>>> ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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%20A
>>>>>>> ND%2
>>>>>>> 0la
>>>>>>> bels%20in%20(performance)
>>>>>>>
>>>>>>> Given that one of the One of the main reasons to use JFX for me
>>>>>>> is to be able to develop with one code base for at least OSX and
>>>>>>> Windows and
>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>
>>>>>>> "JavaFX is a set of graphics and media packages that enables
>>>>>>> developers to design, create, test, debug, and deploy rich client
>>>>>>> applications that operate consistently across diverse platforms"
>>>>>>>
>>>>>>> and the fact that this is clearly not the case currently (8u40)
>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>> performance/quality problems on the Mac, I am a bit unsure what
>>>>>>> to make of all that. Is Mac OSX a second-class citizen as far as
>>>>>>> dev resources are concerned?
>>>>>>>
>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>> performance that can be tracked?
>>>>>>>
>>>>>>> I will file an issue with a simple test case and hope for the
>>>>>>> best.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>> <cnewland at chrisnewland.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Possibly related:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I can reproduce a massive (90%) performance drop on OSX between
>>>>>>>>   drawing a wireframe polygon on a Canvas using a series of
>>>>>>>> gc.strokeLine(double x1, double y1, double x2, double y2)
>>>>>>>> commands versus using a single gc.strokePolygon(double[]
>>>>>>>> xPoints, double[] yPoints, int count) command.
>>>>>>>>
>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>
>>>>>>>> This is reproducible in a little GitHub JavaFX benchmarking
>>>>>>>> project I've
>>>>>>>> created: https://github.com/chriswhocodes/DemoFX
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Build with ant
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Run with:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> # use strokeLine
>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>> result: 60 (sixty) fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> # use strokePolygon
>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>> result: 6 (six) fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM
>>>>>>>> /
>>>>>>>> Radeon
>>>>>>>> 6970M 1024MB
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Looking at the code paths in
>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints,
>>>>>>>>   true, NGCanvas.STROKE_PATH) which involves significantly more
>>>>>>>> work with adding to and flushing a GrowableDataBuffer.
>>>>>>>>
>>>>>>>> I've not had time to dig any deeper than this but it's surely a
>>>>>>>> bug when building a poly manually is 10x faster than using the
>>>>>>>> convenience method.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The bad full screen performance is without the arcs. It is
>>>>>>>>>> just one call to fillRect, two to strokeOval and one to
>>>>>>>>>> fillOval, that's all. I will build a simple test case and
>>>>>>>>>> file an issue.
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please file a Jira issue with a simple test case.  Arcs
>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>> predetermined shader, but it shouldn't be that slow.
>>>>>>>>>>> Something else may
>>>>>>>>>>> be going on.
>>>>>>>>>>>
>>>>>>>>>>> Another test might be to replace the arcs with rectangles
>>>>>>>>>>> or ellipses and see if the performance changes...
>>>>>>>>>>>
>>>>>>>>>>> ...jim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>> AnimationTimer
>>>>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>>>>> operations, i.e. fills the screen with a color and then
>>>>>>>>>>>>   draws and fills 2-3 circles and I have already
>>>>>>>>>>>> observed that each drawing operation I add, results in
>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in
>>>>>>>>>>>> addition to the circles, the CPU load goes up to 30-40%
>>>>>>>>>>>> on a Mac Book Pro
>>>>>>>>>>>> for a Canvas size of 600x600(!).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Now I tested the animation in full screen mode (only
>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>>> performance known to be very bad on Mac or
>>>>>>>>>>>> am I doing something wrong? Are there workarounds for
>>>>>>>>>>>> this?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Robert
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Robert Kr????ger
>>>>>>>>>> Managing Partner
>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> www.lesspain-software.com
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Robert Kr??ger
>>>>>>> Managing Partner
>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> www.lesspain-software.com
>>>>
>>>>
>>>
>>
>>

From james.graham at oracle.com  Wed Apr  8 00:23:44 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 07 Apr 2015 17:23:44 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>	<5515C483.9030901@oracle.com>	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
Message-ID: <55247510.2020006@oracle.com>

If I modify the Sierpinksi program to use moveTo/lineTo/lineTo on a path 
and fill the entire path at once the performance improves dramatically 
on both Intel and nVidia GPUs. It is faster still if I replace the 
triangles with fillRect calls, but not by as large a margin. It would 
appear that we are getting entirely bogged down by uploading lots of 
little alpha coverage tiles for each individual polygon to the GPU (odd 
that this overhead would be greater for the Intel integrated graphics 
that uses main system RAM than the nVidia discrete graphics which uses a 
separate memory system, but there could be something to be said for the 
discrete VRAM being faster).

...jim

On 3/31/15, 1:31 PM, 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/chrisnewland/demofx/standalone/Sierpinski.java
>
> Was full frame rate canvas drawing an expected use case for JavaFX or
> would I be better off with Graphics2D?
>
> Thanks,
>
> Chris
>
> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>> Hi Chris,
>>
>>
>> drawLine() is a very simple primitive that can be optimized with a GPU
>> shader.  It either looks like a (potentially rotated) rectangle or a
>> rounded rect - and we have optimized shaders for both cases.  A large
>> number of drawLine() calls turns into simply accumulating a large vertex
>> list and uploading it to the GPU with an appropriate shader which is very
>> fast.
>>
>> drawPolygon() is a very complex operation that involves things like:
>>
>> - dealing with line joins between segments that don't exist for
>> drawLine() - dealing with only rendering common points of intersection
>> once
>>
>> To handle all of that complexity we have to involve a rasterizer that
>> takes the entire collection of lines, analyzes the stroke attributes and
>> interactions and computes a coverage mask for each pixel in the region. We
>> do that in software currently for all pipelines.
>>
>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
>> rasterization.
>>
>> For the SW pipeline, drawLine is a simplified case of drawPolygon and so
>> the overhead of lots of calls to drawLine() dominates its performance.
>>
>> I would expect ES2 to blow the SW pipeline out of the water with
>> drawLine() performance (as long as there are no additional rendering
>> primitives interspersed in the set of lines).
>>
>> But, both should be on the same footing for the drawPolygon case.  Does
>> the ES2 pipeline compare similarly (hopefully better than) the SW pipeline
>> for the polygon case?
>>
>> One thing I noticed is that we have no optimized case for drawLine() on
>> the SW pipeline.  It generates a path containing a single MOVETO and LINETO
>> and feeds it to the generalized path rasterizer when it could instead
>> compute the rounded/square rectangle and render it more directly.  If we
>> added that support then I'd expect the SW pipeline to perform the set of
>> drawLine calls faster than drawPolygon as well...
>>
>> ...jim
>>
>>
>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>
>>> Hi Robert,
>>>
>>>
>>> I've not filed a Jira yet as I was hoping to find time to investigate
>>> thoroughly but when I saw your question I thought I'd better add my
>>> findings.
>>>
>>> I believe the issue is in the ES2Pipeline as if I run with
>>> -Dprism.order=sw then strokePolygon outperforms the series of strokeLine
>>>   commands as expected:
>>>
>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps
>>>
>>>
>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps
>>>
>>>
>>> Will see if I can find the root cause as I've got plenty more examples
>>> where ES2Pipeline performs horribly on my Mac which should have no
>>> problem throwing around a few thousand polys.
>>>
>>> I realise there's a *lot* of indirection involved in making JavaFX
>>> support such a wide range of underlying graphics systems but I do think
>>> there's a bug here.
>>>
>>> Will file a Jira if I can contribute a bit more than "feels slow" ;)
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Chris
>>>
>>>
>>> On Sat, March 28, 2015 10:06, Robert Kr??ger wrote:
>>>
>>>> This is consistent with what I am observing. Is this something that
>>>> Oracle
>>>> is aware of? Looking at Jira, I don't see that anyone is working on
>>>> this:
>>>>
>>>>
>>>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%2
>>>> 2In%
>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%2
>>>> 0la
>>>> bels%20in%20(performance)
>>>>
>>>> Given that one of the One of the main reasons to use JFX for me is to
>>>> be able to develop with one code base for at least OSX and Windows and
>>>> the official statement what JavaFX is for, i.e.
>>>>
>>>> "JavaFX is a set of graphics and media packages that enables
>>>> developers to design, create, test, debug, and deploy rich client
>>>> applications that operate consistently across diverse platforms"
>>>>
>>>> and the fact that this is clearly not the case currently (8u40) as
>>>> soon as I do something else than simple forms, I run into
>>>> performance/quality problems on the Mac, I am a bit unsure what to
>>>> make of all that. Is Mac OSX
>>>> a second-class citizen as far as dev resources are concerned?
>>>>
>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>> performance that can be tracked?
>>>>
>>>> I will file an issue with a simple test case and hope for the best.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>> <cnewland at chrisnewland.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Possibly related:
>>>>>
>>>>>
>>>>>
>>>>> I can reproduce a massive (90%) performance drop on OSX between
>>>>> drawing a wireframe polygon on a Canvas using a series of
>>>>> gc.strokeLine(double x1, double y1, double x2, double y2) commands
>>>>> versus using a single gc.strokePolygon(double[] xPoints, double[]
>>>>> yPoints, int count) command.
>>>>>
>>>>> Creating the polygons manually with strokeLine() is significantly
>>>>> faster using the ES2Pipeline on OSX.
>>>>>
>>>>> This is reproducible in a little GitHub JavaFX benchmarking project
>>>>>   I've
>>>>> created: https://github.com/chriswhocodes/DemoFX
>>>>>
>>>>>
>>>>>
>>>>> Build with ant
>>>>>
>>>>>
>>>>>
>>>>> Run with:
>>>>>
>>>>>
>>>>>
>>>>> # use strokeLine
>>>>> ./run.sh -c 5000 -m line
>>>>> result: 60 (sixty) fps
>>>>>
>>>>>
>>>>>
>>>>> # use strokePolygon
>>>>> ./run.sh -c 5000 -m poly
>>>>> result: 6 (six) fps
>>>>>
>>>>>
>>>>>
>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM /
>>>>> Radeon
>>>>> 6970M 1024MB
>>>>>
>>>>>
>>>>>
>>>>> Looking at the code paths in javafx.scene.canvas.GraphicsContext:
>>>>>
>>>>>
>>>>>
>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>> NGCanvas.STROKE_LINE)
>>>>>
>>>>>
>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints,
>>>>> true, NGCanvas.STROKE_PATH) which involves significantly more work
>>>>> with adding to and flushing a GrowableDataBuffer.
>>>>>
>>>>> I've not had time to dig any deeper than this but it's surely a bug
>>>>>   when building a poly manually is 10x faster than using the
>>>>> convenience method.
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>
>>>>>
>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>
>>>>>>
>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>> <krueger at lesspain.de>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The bad full screen performance is without the arcs. It is just
>>>>>>> one call to fillRect, two to strokeOval and one to fillOval,
>>>>>>> that's all. I will build a simple test case and file an issue.
>>>>>>>
>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>> <james.graham at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please file a Jira issue with a simple test case.  Arcs are
>>>>>>>> handled as a generalized shape rather than via a predetermined
>>>>>>>>   shader, but it shouldn't be that slow.  Something else may
>>>>>>>> be going on.
>>>>>>>>
>>>>>>>> Another test might be to replace the arcs with rectangles or
>>>>>>>> ellipses and see if the performance changes...
>>>>>>>>
>>>>>>>> ...jim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>> AnimationTimer
>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>> operations, i.e. fills the screen with a color and then
>>>>>>>>> draws and fills 2-3 circles and I have already observed that
>>>>>>>>> each drawing operation I add, results in
>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in addition
>>>>>>>>> to the circles, the CPU load goes up to 30-40% on a Mac Book
>>>>>>>>> Pro
>>>>>>>>> for a Canvas size of 600x600(!).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now I tested the animation in full screen mode (only with a
>>>>>>>>> few circles) and playback is unusable for a serious
>>>>>>>>> application (very
>>>>>>>>> choppy). Is 2D canvas performance known to be very bad on
>>>>>>>>> Mac or
>>>>>>>>> am I doing something wrong? Are there workarounds for this?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Robert Kr????ger
>>>>>>> Managing Partner
>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> www.lesspain-software.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Robert Kr??ger
>>>> Managing Partner
>>>> Lesspain GmbH & Co. KG
>>>>
>>>>
>>>>
>>>> www.lesspain-software.com
>>>>
>>>
>


From krueger at lesspain.de  Wed Apr  8 06:57:12 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 Apr 2015 08:57:12 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <5524654C.2060500@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
Message-ID: <CAEnqZEXKNhXvfEzeTReBwJiDASJBuHPfusBKzGuizrMvddpojQ@mail.gmail.com>

All my MBP numbers are on integrated Intel graphics as well. I tested on an
old MBP that only has Intel graphics and on my more recent MBP the Nvidia
is deactivated due to a problem with it.

On Wed, Apr 8, 2015 at 1:16 AM, Jim Graham <james.graham at oracle.com> 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 <cnewland at chrisnewland.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Jim,
>>>>>
>>>>>
>>>>> Thanks, that makes things much clearer.
>>>>>
>>>>>
>>>>> I was surprised how much was going on under the hood of GraphicsContext
>>>>>   and hoped it was just magic glue that gave the best of GPU
>>>>> acceleration where available and immediate-mode-like simple rasterizing
>>>>> where not.
>>>>>
>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon where
>>>>> the software pipeline achieves the full 60fps but ES2 can only manage
>>>>> 30-35fps. It uses lots of overlapping filled triangles so I expect
>>>>> suffers from the problem you've described.
>>>>>
>>>>> SSCCE:
>>>>> https://github.com/chriswhocodes/DemoFX/blob/
>>>>> master/src/main/java/com/ch
>>>>>
>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>
>>>>> Was full frame rate canvas drawing an expected use case for JavaFX or
>>>>> would I be better off with Graphics2D?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>  On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>>
>>>>>>
>>>>>> drawLine() is a very simple primitive that can be optimized with a
>>>>>> GPU
>>>>>> shader.  It either looks like a (potentially rotated) rectangle or a
>>>>>> rounded rect - and we have optimized shaders for both cases.  A large
>>>>>>   number of drawLine() calls turns into simply accumulating a large
>>>>>> vertex list and uploading it to the GPU with an appropriate shader
>>>>>> which is very fast.
>>>>>>
>>>>>> drawPolygon() is a very complex operation that involves things like:
>>>>>>
>>>>>> - dealing with line joins between segments that don't exist for
>>>>>> drawLine() - dealing with only rendering common points of intersection
>>>>>>   once
>>>>>>
>>>>>> To handle all of that complexity we have to involve a rasterizer that
>>>>>>   takes the entire collection of lines, analyzes the stroke attributes
>>>>>> and interactions and computes a coverage mask for each pixel in the
>>>>>> region. We do that in software currently for all pipelines.
>>>>>>
>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path
>>>>>>   rasterization.
>>>>>>
>>>>>> For the SW pipeline, drawLine is a simplified case of drawPolygon and
>>>>>> so the overhead of lots of calls to drawLine() dominates its
>>>>>> performance.
>>>>>>
>>>>>> I would expect ES2 to blow the SW pipeline out of the water with
>>>>>> drawLine() performance (as long as there are no additional rendering
>>>>>> primitives interspersed in the set of lines).
>>>>>>
>>>>>> But, both should be on the same footing for the drawPolygon case.
>>>>>> Does
>>>>>> the ES2 pipeline compare similarly (hopefully better than) the SW
>>>>>> pipeline for the polygon case?
>>>>>>
>>>>>> One thing I noticed is that we have no optimized case for drawLine()
>>>>>> on the SW pipeline.  It generates a path containing a single MOVETO
>>>>>> and LINETO and feeds it to the generalized path rasterizer when it
>>>>>> could instead compute the rounded/square rectangle and render it more
>>>>>> directly.  If we added that support then I'd expect the SW pipeline to
>>>>>> perform the set of drawLine calls faster than drawPolygon as well...
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>> investigate thoroughly but when I saw your question I thought I'd
>>>>>>> better add my findings.
>>>>>>>
>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>> strokeLine commands as expected:
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result:
>>>>>>> 44fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result:
>>>>>>> 60fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>> examples where ES2Pipeline performs horribly on my Mac which should
>>>>>>> have no problem throwing around a few thousand polys.
>>>>>>>
>>>>>>> I realise there's a *lot* of indirection involved in making JavaFX
>>>>>>> support such a wide range of underlying graphics systems but I do
>>>>>>> think there's a bug here.
>>>>>>>
>>>>>>> Will file a Jira if I can contribute a bit more than "feels slow"
>>>>>>> ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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%20A
>>>>>>>> ND%2
>>>>>>>> 0la
>>>>>>>> bels%20in%20(performance)
>>>>>>>>
>>>>>>>> Given that one of the One of the main reasons to use JFX for me
>>>>>>>> is to be able to develop with one code base for at least OSX and
>>>>>>>> Windows and
>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>
>>>>>>>> "JavaFX is a set of graphics and media packages that enables
>>>>>>>> developers to design, create, test, debug, and deploy rich client
>>>>>>>> applications that operate consistently across diverse platforms"
>>>>>>>>
>>>>>>>> and the fact that this is clearly not the case currently (8u40)
>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>> performance/quality problems on the Mac, I am a bit unsure what
>>>>>>>> to make of all that. Is Mac OSX a second-class citizen as far as
>>>>>>>> dev resources are concerned?
>>>>>>>>
>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>> performance that can be tracked?
>>>>>>>>
>>>>>>>> I will file an issue with a simple test case and hope for the
>>>>>>>> best.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  Possibly related:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX between
>>>>>>>>>   drawing a wireframe polygon on a Canvas using a series of
>>>>>>>>> gc.strokeLine(double x1, double y1, double x2, double y2)
>>>>>>>>> commands versus using a single gc.strokePolygon(double[]
>>>>>>>>> xPoints, double[] yPoints, int count) command.
>>>>>>>>>
>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>
>>>>>>>>> This is reproducible in a little GitHub JavaFX benchmarking
>>>>>>>>> project I've
>>>>>>>>> created: https://github.com/chriswhocodes/DemoFX
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Build with ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Run with:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokeLine
>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokePolygon
>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>> result: 6 (six) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM
>>>>>>>>> /
>>>>>>>>> Radeon
>>>>>>>>> 6970M 1024MB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looking at the code paths in
>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints,
>>>>>>>>>   true, NGCanvas.STROKE_PATH) which involves significantly more
>>>>>>>>> work with adding to and flushing a GrowableDataBuffer.
>>>>>>>>>
>>>>>>>>> I've not had time to dig any deeper than this but it's surely a
>>>>>>>>> bug when building a poly manually is 10x faster than using the
>>>>>>>>> convenience method.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  In my opinion the whole graphics performance on MacOSX
>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The bad full screen performance is without the arcs. It is
>>>>>>>>>>> just one call to fillRect, two to strokeOval and one to
>>>>>>>>>>> fillOval, that's all. I will build a simple test case and
>>>>>>>>>>> file an issue.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Hi Robert,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please file a Jira issue with a simple test case.  Arcs
>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>> predetermined shader, but it shouldn't be that slow.
>>>>>>>>>>>> Something else may
>>>>>>>>>>>> be going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Another test might be to replace the arcs with rectangles
>>>>>>>>>>>> or ellipses and see if the performance changes...
>>>>>>>>>>>>
>>>>>>>>>>>> ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>> AnimationTimer
>>>>>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>>>>>> operations, i.e. fills the screen with a color and then
>>>>>>>>>>>>>   draws and fills 2-3 circles and I have already
>>>>>>>>>>>>> observed that each drawing operation I add, results in
>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in
>>>>>>>>>>>>> addition to the circles, the CPU load goes up to 30-40%
>>>>>>>>>>>>> on a Mac Book Pro
>>>>>>>>>>>>> for a Canvas size of 600x600(!).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I tested the animation in full screen mode (only
>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>> performance known to be very bad on Mac or
>>>>>>>>>>>>> am I doing something wrong? Are there workarounds for
>>>>>>>>>>>>> this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Kr??ger
>>>>>>>> Managing Partner
>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> www.lesspain-software.com
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>


-- 
Robert Kr?ger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

From johan at lodgon.com  Wed Apr  8 07:12:21 2015
From: johan at lodgon.com (Johan Vos)
Date: Wed, 8 Apr 2015 09:12:21 +0200
Subject: performance on iOS
Message-ID: <CABek58=oN6NY6q8uL_3dWFKGEACq_22yeigDTWO9xzXAVZA+0g@mail.gmail.com>

Hi,

I did some performance tests on Android and iOS. I am using
https://github.com/Ciruman/DemoFX.git which is forked from
https://github.com/chriswhocodes/DemoFX and made mobile-ready.

On my Nexus 5, I easily get 30 fps with triangles (the first test). On my
old iPad, this is only 3 fps. I've reports we achieve 5-6 fps on an iPad
Air.

Digging into the potential bottlenecks, I found out that the native
function responsible for 50% of the CPU time is glTexSubImage2D which seems
to be slow on iOS (e.g. see
http://stackoverflow.com/questions/21162688/gltexsubimage2d-slow-on-ios7)
but it is heavily used in prism-es2.

Any advice?

Thanks,

- Johan

From derijcke.erik at gmail.com  Wed Apr  8 07:45:33 2015
From: derijcke.erik at gmail.com (Erik De Rijcke)
Date: Wed, 8 Apr 2015 09:45:33 +0200
Subject: performance on iOS
In-Reply-To: <CABek58=oN6NY6q8uL_3dWFKGEACq_22yeigDTWO9xzXAVZA+0g@mail.gmail.com>
References: <CABek58=oN6NY6q8uL_3dWFKGEACq_22yeigDTWO9xzXAVZA+0g@mail.gmail.com>
Message-ID: <CABO6FzQJuhiC8T=2MhA3sDuiEbUyAcZ-12aAKk1_ZhdizSWsEw@mail.gmail.com>

Disclaimer: I have not looked at the demo you're trying to run. I'm no
opengl expert so my advice might be a bit off, but I do know the basics of
gl programming.

I'm not familiar with JavaFX opengl rendering algorithm but is it really
needed to create a new (sub)texture object so many times? You're basically
asking the GPU to allocate a new piece of vmemory every time *and*
uploading your data to it *and* destroying it afterwards when no longer
needed... It might be better to either cache your textures and upload your
data to it async (lots of methods to do that online) or have some kind of
texture atlas or most likely: revise the way the jfx rendering algorithm
works. Also, you're profiling CPU time of the glTexSubImage2D function,
which might stall (sync call possibly) on iOS if the gpu is busy.



On Wed, Apr 8, 2015 at 9:12 AM, Johan Vos <johan at lodgon.com> wrote:

> Hi,
>
> I did some performance tests on Android and iOS. I am using
> https://github.com/Ciruman/DemoFX.git which is forked from
> https://github.com/chriswhocodes/DemoFX and made mobile-ready.
>
> On my Nexus 5, I easily get 30 fps with triangles (the first test). On my
> old iPad, this is only 3 fps. I've reports we achieve 5-6 fps on an iPad
> Air.
>
> Digging into the potential bottlenecks, I found out that the native
> function responsible for 50% of the CPU time is glTexSubImage2D which seems
> to be slow on iOS (e.g. see
> http://stackoverflow.com/questions/21162688/gltexsubimage2d-slow-on-ios7)
> but it is heavily used in prism-es2.
>
> Any advice?
>
> Thanks,
>
> - Johan
>

From anton.tarasov at oracle.com  Wed Apr  8 15:40:27 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Wed, 08 Apr 2015 18:40:27 +0300
Subject: [9] Request for review: RT-40330 [WebView] implement missing
	functionality in PasteboardJava.cpp
Message-ID: <55254BEB.3070502@oracle.com>

Hi Kevin, Vadim,

Please have a look at the WebView Pasteboard refactoring fix:

jira: https://javafx-jira.kenai.com/browse/RT-40330
fix: http://cr.openjdk.java.net/~ant/RT-40330/webrev.0

Thanks,
Anton.

From krueger at lesspain.de  Wed Apr  8 16:14:12 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 Apr 2015 18:14:12 +0200
Subject: Private APIs not usable in Java 9?
Message-ID: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>

Hi,

I hope this is not too off-topic, because although it came up in a JFX
context it's not strictly JFX-only.

Someone from our team recently had a chat with a high-ranking regional
Oracle representative who gave a talk on the state of JFX. Our guy
explained our situation (evaluating JFX to migrate our swing-based product,
feeling it's in principle the right technology but still having
show-stopping limitations like RT-36215) and the Oracle guy offered to
relay our concrete questions to the right people, which he did.

The answer we got contained one thing that really was a bit of a shock and
I would like someone to either confirm this or clear up a misunderstanding.

The statement was that private APIs will not be available in JDK 9 due to
modularity restrictions. If that is the case and we no longer have the
ability to build temporary workarounds using private APIs (which in our
case is controllable as we ship the JRE with our product), I would probably
have to stop any development going into the direction of JFX as we will
probably have to use 9 at some point because many things now scheduled for
9 will not get fixed in 8 and we will most likely still need workarounds
using private API, at least that's what my current experience with JFX
tells me.

Please tell me that this was a misunderstanding (maybe meant for the
general case where one does not ship the JRE) or a non-engineering source
that simply made mistake.

Best regards and thanks in advance,

Robert

From cnewland at chrisnewland.com  Wed Apr  8 16:25:13 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Wed, 8 Apr 2015 17:25:13 +0100
Subject: Canvas performance on Mac OS
In-Reply-To: <5524654C.2060500@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
Message-ID: <058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>

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
>>>>> <cnewland at chrisnewland.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi Jim,
>>>>>
>>>>>
>>>>>
>>>>> Thanks, that makes things much clearer.
>>>>>
>>>>>
>>>>>
>>>>> I was surprised how much was going on under the hood of
>>>>> GraphicsContext
>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>> acceleration where available and immediate-mode-like simple
>>>>> rasterizing where not.
>>>>>
>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>> so I expect suffers from the problem you've described.
>>>>>
>>>>> SSCCE:
>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>> com/ch
>>>>>
>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>
>>>>> Was full frame rate canvas drawing an expected use case for
>>>>> JavaFX or
>>>>> would I be better off with Graphics2D?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>> with a GPU
>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>> with an appropriate shader which is very fast.
>>>>>>
>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>> like:
>>>>>>
>>>>>>
>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>  drawLine() - dealing with only rendering common points of
>>>>>> intersection once
>>>>>>
>>>>>> To handle all of that complexity we have to involve a
>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>> mask for each pixel in the region. We do that in software
>>>>>> currently for all pipelines.
>>>>>>
>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>> CPU path
>>>>>> rasterization.
>>>>>>
>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>> dominates its performance.
>>>>>>
>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>> with drawLine() performance (as long as there are no additional
>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>
>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>> case. Does
>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>> SW
>>>>>> pipeline for the polygon case?
>>>>>>
>>>>>> One thing I noticed is that we have no optimized case for
>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>> rectangle and render it more directly.  If we added that support
>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>> calls faster than drawPolygon as well...
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>> I'd
>>>>>>> better add my findings.
>>>>>>>
>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>> strokeLine commands as expected:
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>> Result:
>>>>>>> 44fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>> Result:
>>>>>>> 60fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>  examples where ES2Pipeline performs horribly on my Mac which
>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>
>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>> JavaFX
>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>> do think there's a bug here.
>>>>>>>
>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>> slow" ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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(Op
>>>>>>>> en%2C% 20%2
>>>>>>>> 2In%
>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>> 20%20A
>>>>>>>> ND%2
>>>>>>>> 0la
>>>>>>>> bels%20in%20(performance)
>>>>>>>>
>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>> least OSX and Windows and
>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>
>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>> across diverse platforms"
>>>>>>>>
>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>> (8u40)
>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>  performance/quality problems on the Mac, I am a bit unsure
>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>> as far as dev resources are concerned?
>>>>>>>>
>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>> performance that can be tracked?
>>>>>>>>
>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>> the best.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Possibly related:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>> double y2) commands versus using a single
>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>> count) command.
>>>>>>>>>
>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>
>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>> benchmarking project I've created:
>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Build with ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Run with:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokeLine
>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokePolygon
>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>> result: 6 (six) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>> 20GB RAM
>>>>>>>>> /
>>>>>>>>> Radeon
>>>>>>>>> 6970M 1024MB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looking at the code paths in
>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>> than using the convenience method.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>> It is
>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>> Arcs
>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>  predetermined shader, but it shouldn't be that
>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>> be going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>> changes...
>>>>>>>>>>>>
>>>>>>>>>>>> ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>  AnimationTimer
>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>> (only
>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>  serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>> this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Kr??ger
>>>>>>>> Managing Partner
>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> www.lesspain-software.com
>>>>>
>>>>>
>>>>
>>>
>>>
>



From mike at plan99.net  Wed Apr  8 16:28:06 2015
From: mike at plan99.net (Mike Hearn)
Date: Wed, 8 Apr 2015 18:28:06 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
Message-ID: <CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>

sed -i 's/private/public/g' ;)

The whole notion of a strongly enforced private keyword is IMHO dumb when
not using sandboxing. The number of gross hacks that occur in an attempt to
work around overly strict enforcement of this stuff is crazy. The D
compiler has a special flag that disables visibility enforcement when
compiling unit tests, and that's a good idea, but why not go all the way
and just make accessing of private state a compiler warning a la deprecated?

I also need to use private JFX APIs. I think any real JFX app does, way too
much basic stuff relies on it. Heck, the number of popular Java libraries
that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
this regard then I will just write a simple tool that flips private->public
either at the source level or via bytecode editing, and see what happens :-)


On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> wrote:

> Hi,
>
> I hope this is not too off-topic, because although it came up in a JFX
> context it's not strictly JFX-only.
>
> Someone from our team recently had a chat with a high-ranking regional
> Oracle representative who gave a talk on the state of JFX. Our guy
> explained our situation (evaluating JFX to migrate our swing-based product,
> feeling it's in principle the right technology but still having
> show-stopping limitations like RT-36215) and the Oracle guy offered to
> relay our concrete questions to the right people, which he did.
>
> The answer we got contained one thing that really was a bit of a shock and
> I would like someone to either confirm this or clear up a misunderstanding.
>
> The statement was that private APIs will not be available in JDK 9 due to
> modularity restrictions. If that is the case and we no longer have the
> ability to build temporary workarounds using private APIs (which in our
> case is controllable as we ship the JRE with our product), I would probably
> have to stop any development going into the direction of JFX as we will
> probably have to use 9 at some point because many things now scheduled for
> 9 will not get fixed in 8 and we will most likely still need workarounds
> using private API, at least that's what my current experience with JFX
> tells me.
>
> Please tell me that this was a misunderstanding (maybe meant for the
> general case where one does not ship the JRE) or a non-engineering source
> that simply made mistake.
>
> Best regards and thanks in advance,
>
> Robert
>

From kevin.rushforth at oracle.com  Wed Apr  8 16:37:00 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 08 Apr 2015 09:37:00 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
Message-ID: <5525592C.4020803@oracle.com>

Hi Robert,

No, this is not a misunderstanding. There will be no access to any 
classes in non-public packages in JDK 9 by applications for exactly the 
reasons the region rep mentioned. For JavaFX this means that no 
com.sun.javafx (or similar) packages will be accessible by applications 
in JDK 9.

I note that this is not limited to JavaFX. It has already been discussed 
on the awt list, for example (the java.awt.peer package will not be 
exported). And you won't be able to use sun.* classes or internal 
classes on Swing, etc.

Note that if you build your own JDK with FX you will be able to modify 
classes for your own use to workaround problems, but you will no longer 
be able to simply call into com.sun.javafx.SomeClass for a workaround.

There is a good possibility that the JDK will provide a -XX 
"compatibliity" switch to relax module boundaries (when there is no 
security manager present) in JDK 9 to ease the pain of transition, but 
that will be a temporary stop-gap not a long-term solution.

-- Kevin


Robert Kr?ger wrote:
> Hi,
>
> I hope this is not too off-topic, because although it came up in a JFX
> context it's not strictly JFX-only.
>
> Someone from our team recently had a chat with a high-ranking regional
> Oracle representative who gave a talk on the state of JFX. Our guy
> explained our situation (evaluating JFX to migrate our swing-based product,
> feeling it's in principle the right technology but still having
> show-stopping limitations like RT-36215) and the Oracle guy offered to
> relay our concrete questions to the right people, which he did.
>
> The answer we got contained one thing that really was a bit of a shock and
> I would like someone to either confirm this or clear up a misunderstanding.
>
> The statement was that private APIs will not be available in JDK 9 due to
> modularity restrictions. If that is the case and we no longer have the
> ability to build temporary workarounds using private APIs (which in our
> case is controllable as we ship the JRE with our product), I would probably
> have to stop any development going into the direction of JFX as we will
> probably have to use 9 at some point because many things now scheduled for
> 9 will not get fixed in 8 and we will most likely still need workarounds
> using private API, at least that's what my current experience with JFX
> tells me.
>
> Please tell me that this was a misunderstanding (maybe meant for the
> general case where one does not ship the JRE) or a non-engineering source
> that simply made mistake.
>
> Best regards and thanks in advance,
>
> Robert
>   

From joe.mcglynn at oracle.com  Wed Apr  8 16:38:03 2015
From: joe.mcglynn at oracle.com (Joe McGlynn)
Date: Wed, 8 Apr 2015 09:38:03 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
Message-ID: <D7694D09-FB57-48B2-B2F9-25F3F5BC627F@oracle.com>

If there are FX APIs that are currently private that folks think should be public, or that are currently necessary to implement a work-around for another bug, please make sure there is a Jira issue filed for this.  

We?ll try to address this for JDK 9 to mitigate this, but everyone should understand that as part of Jigsaw it?s expected that ALL private APIs will become unavailable in Java. 
 <http://www.oracle.com/commitment>

 <http://www.oracle.com/commitment>
> On Apr 8, 2015, at 9:28 AM, Mike Hearn <mike at plan99.net> wrote:
> 
> sed -i 's/private/public/g' ;)
> 
> The whole notion of a strongly enforced private keyword is IMHO dumb when
> not using sandboxing. The number of gross hacks that occur in an attempt to
> work around overly strict enforcement of this stuff is crazy. The D
> compiler has a special flag that disables visibility enforcement when
> compiling unit tests, and that's a good idea, but why not go all the way
> and just make accessing of private state a compiler warning a la deprecated?
> 
> I also need to use private JFX APIs. I think any real JFX app does, way too
> much basic stuff relies on it. Heck, the number of popular Java libraries
> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
> this regard then I will just write a simple tool that flips private->public
> either at the source level or via bytecode editing, and see what happens :-)
> 
> 
> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
> 
>> Hi,
>> 
>> I hope this is not too off-topic, because although it came up in a JFX
>> context it's not strictly JFX-only.
>> 
>> Someone from our team recently had a chat with a high-ranking regional
>> Oracle representative who gave a talk on the state of JFX. Our guy
>> explained our situation (evaluating JFX to migrate our swing-based product,
>> feeling it's in principle the right technology but still having
>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>> relay our concrete questions to the right people, which he did.
>> 
>> The answer we got contained one thing that really was a bit of a shock and
>> I would like someone to either confirm this or clear up a misunderstanding.
>> 
>> The statement was that private APIs will not be available in JDK 9 due to
>> modularity restrictions. If that is the case and we no longer have the
>> ability to build temporary workarounds using private APIs (which in our
>> case is controllable as we ship the JRE with our product), I would probably
>> have to stop any development going into the direction of JFX as we will
>> probably have to use 9 at some point because many things now scheduled for
>> 9 will not get fixed in 8 and we will most likely still need workarounds
>> using private API, at least that's what my current experience with JFX
>> tells me.
>> 
>> Please tell me that this was a misunderstanding (maybe meant for the
>> general case where one does not ship the JRE) or a non-engineering source
>> that simply made mistake.
>> 
>> Best regards and thanks in advance,
>> 
>> Robert
>> 


From philip.race at oracle.com  Wed Apr  8 16:44:17 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 08 Apr 2015 09:44:17 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
Message-ID: <55255AE1.2070302@oracle.com>


 >  it's not strictly JFX-only.

Its not remotely FX only, in fact I could argue FX is not so affected,
as being relatively new it does not have 20 years of accumulation
of people using internal APIs that the larger JDK does, often dating from
when there were no suitable public APIs. There still remains some
of that with sun.misc.Unsafe as pointed out which will indeed be
inaccessible in modular mode. But the FX list isn't really the place
for that discussion. The jigsaw-dev is the appropriate list. FX
is simply bound by the rules that are set there.

There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
transition.

Also remember FX is open source. You can propose patches !
If there are specific APIs that are missing from FX that are suitable
to be *supported* public APIs then those could be considered here (this 
list).

-phil.

On 4/8/2015 9:28 AM, Mike Hearn wrote:
> sed -i 's/private/public/g' ;)
>
> The whole notion of a strongly enforced private keyword is IMHO dumb when
> not using sandboxing. The number of gross hacks that occur in an attempt to
> work around overly strict enforcement of this stuff is crazy. The D
> compiler has a special flag that disables visibility enforcement when
> compiling unit tests, and that's a good idea, but why not go all the way
> and just make accessing of private state a compiler warning a la deprecated?
>
> I also need to use private JFX APIs. I think any real JFX app does, way too
> much basic stuff relies on it. Heck, the number of popular Java libraries
> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
> this regard then I will just write a simple tool that flips private->public
> either at the source level or via bytecode editing, and see what happens :-)
>
>
> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>
>> Hi,
>>
>> I hope this is not too off-topic, because although it came up in a JFX
>> context it's not strictly JFX-only.
>>
>> Someone from our team recently had a chat with a high-ranking regional
>> Oracle representative who gave a talk on the state of JFX. Our guy
>> explained our situation (evaluating JFX to migrate our swing-based product,
>> feeling it's in principle the right technology but still having
>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>> relay our concrete questions to the right people, which he did.
>>
>> The answer we got contained one thing that really was a bit of a shock and
>> I would like someone to either confirm this or clear up a misunderstanding.
>>
>> The statement was that private APIs will not be available in JDK 9 due to
>> modularity restrictions. If that is the case and we no longer have the
>> ability to build temporary workarounds using private APIs (which in our
>> case is controllable as we ship the JRE with our product), I would probably
>> have to stop any development going into the direction of JFX as we will
>> probably have to use 9 at some point because many things now scheduled for
>> 9 will not get fixed in 8 and we will most likely still need workarounds
>> using private API, at least that's what my current experience with JFX
>> tells me.
>>
>> Please tell me that this was a misunderstanding (maybe meant for the
>> general case where one does not ship the JRE) or a non-engineering source
>> that simply made mistake.
>>
>> Best regards and thanks in advance,
>>
>> Robert
>>


From krueger at lesspain.de  Wed Apr  8 17:15:24 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 Apr 2015 19:15:24 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <F89BF02D-9F1E-4D20-A294-92B09D0A7486@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<F89BF02D-9F1E-4D20-A294-92B09D0A7486@oracle.com>
Message-ID: <CAEnqZEUecmHK4a8CmrfAR3p+pyoYQuJditc_uDz6NO3DpmTV+g@mail.gmail.com>

OK, if that statement holds true it is not too unlikely it will be the
death of our plans to migrate to JFX (which I am trying to convince my
partners of). I am aware that using private APIs is a last resort and we
don't do that if we don't have to. Realistically the pace at which JFX
(which we think is a great technology btw.) matures, it is currently the
only way to handle the risk of running into something that does not work
(yet), which has happened to me many times just beginning to dive into
migration. Simply stating "it's not a good idea to do this" and hoping it's
going to work is ignoring the facts and I will probably not bet my business
on JFX without everything we lose, if enforcement of this is mandatory in
Java 9. Just looking at a few things in Jira, it is obvious that you are
already scheduling rather serious problems to Java 9 and I am not expecting
this to change very soon, because Oracle suddenly doubles the dev resources
for JFX. Taking away this (admittedly very ugly) way for developers to help
themselves at their own risk (in many cases until something is
fixed/implemented in the JDK by Oracle, which, of course, takes more time
than a hack) is IMHO not a good idea in the current phase of JFX. You will
probably lose yet more originally very interested software vendors who will
disappointedly move to native technologies because they simply cannot
deliver the product they want/have to, although they'd rather use Java
(FX). But, of course, it's your decision and legitimate to do it either
way. I'm just trying to show you a side here (that I think a number of
other ISVs here on the list know), that might need a little lobbying.

On the other hand, I would guess that deactivating the enforcement of this
in OpenJDK will probably not be too difficult anyway, so if you decide not
to offer to make this configurable one could find a way by building a
modified OpenJDK and shipping that but it would be nicer if Oracle would
acknowledge that this helps some people at this stage and offer it. After
all some of those people are JFX lobbyists out there and there are not many
at the moment compared to the competing technologies.

It all may be a different situation a few years from now when JFX has
matured and seen a few thousand serious commercial applications built on
top of it.

On Wed, Apr 8, 2015 at 6:25 PM, Joe McGlynn <joe.mcglynn at oracle.com> wrote:

> This is unrelated to FX, no Java applications will be able to use private
> APIs in JDK 9.  There _may_ be a temporary compatibility mode, but clearly
> use of them is not something you should plan on regardless of UI technology.
>

From krueger at lesspain.de  Wed Apr  8 17:23:09 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 Apr 2015 19:23:09 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEUecmHK4a8CmrfAR3p+pyoYQuJditc_uDz6NO3DpmTV+g@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<F89BF02D-9F1E-4D20-A294-92B09D0A7486@oracle.com>
	<CAEnqZEUecmHK4a8CmrfAR3p+pyoYQuJditc_uDz6NO3DpmTV+g@mail.gmail.com>
Message-ID: <CAEnqZEURds0KTJhURmVEB6xjM2Zkf0uiqEti-iFMVkTEm3iVNA@mail.gmail.com>

OK, while I wrote this, all the other replies came in. So I see that your
recommendation for the cases I mentioned is then to patch OpenJDK and
submit Jira issues. Fair enough.

Regarding Jira issues, we are already doing that. Regarding code
contribution, this is a different thing, because in many cases a hack to
expose something that should be there is quick but designing a consistent
API that exposes the missing things is often something that requires a
different qualification.


>

From tomas.mikula at gmail.com  Wed Apr  8 18:22:16 2015
From: tomas.mikula at gmail.com (Tomas Mikula)
Date: Wed, 8 Apr 2015 14:22:16 -0400
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEURds0KTJhURmVEB6xjM2Zkf0uiqEti-iFMVkTEm3iVNA@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<F89BF02D-9F1E-4D20-A294-92B09D0A7486@oracle.com>
	<CAEnqZEUecmHK4a8CmrfAR3p+pyoYQuJditc_uDz6NO3DpmTV+g@mail.gmail.com>
	<CAEnqZEURds0KTJhURmVEB6xjM2Zkf0uiqEti-iFMVkTEm3iVNA@mail.gmail.com>
Message-ID: <CA+THrurhhb=n76L1Zzs0oXZCtJ1ayaTxg--_uevhONeyH4by6w@mail.gmail.com>

My concern is that issues with existing workarounds were given lower
priority. Now many workarounds will disappear, but I'm worried that
the priorities will not be reconsidered.

I think part of the problem is the fact that Java does not have a good
way of marking an API as experimental. Anything public can never
change, so JDK developers don't make things public if they are not
quite happy with the API yet, even though some bits would be useful
for others. As a consequence, they get no or very little feedback on a
private API, thus slowing the progress towards the non-experimental
API even more. Sure, experimental functionality could still be dropped
at any time, but that is not happening here. The functionality
remains, it is just going to be hidden.

Robert makes a good point that designing a stable API for something
that is currently private and possibly ugly is much more work than
pulling ad-hoc hacks with the experimental API. I believe Jira issues
are mostly there, I'm just skeptical that all of the issues currently
targeted for 9 will actually be resolved in 9.

On Wed, Apr 8, 2015 at 1:23 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
> OK, while I wrote this, all the other replies came in. So I see that your
> recommendation for the cases I mentioned is then to patch OpenJDK and
> submit Jira issues. Fair enough.
>
> Regarding Jira issues, we are already doing that. Regarding code
> contribution, this is a different thing, because in many cases a hack to
> expose something that should be there is quick but designing a consistent
> API that exposes the missing things is often something that requires a
> different qualification.
>
>
>>

From herve.girod at gmail.com  Wed Apr  8 18:46:39 2015
From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=)
Date: Wed, 8 Apr 2015 20:46:39 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CA+THrurhhb=n76L1Zzs0oXZCtJ1ayaTxg--_uevhONeyH4by6w@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<F89BF02D-9F1E-4D20-A294-92B09D0A7486@oracle.com>
	<CAEnqZEUecmHK4a8CmrfAR3p+pyoYQuJditc_uDz6NO3DpmTV+g@mail.gmail.com>
	<CAEnqZEURds0KTJhURmVEB6xjM2Zkf0uiqEti-iFMVkTEm3iVNA@mail.gmail.com>
	<CA+THrurhhb=n76L1Zzs0oXZCtJ1ayaTxg--_uevhONeyH4by6w@mail.gmail.com>
Message-ID: <B97D13E6-CD80-4FB7-8CC5-A7D02355255D@gmail.com>

I think that Oracle people are right. It's more a JDK 9 or jigsaw issue than a JavaFX issue.

Sent from my iPhone

> On Apr 8, 2015, at 20:22, Tomas Mikula <tomas.mikula at gmail.com> wrote:
> 
> My concern is that issues with existing workarounds were given lower
> priority. Now many workarounds will disappear, but I'm worried that
> the priorities will not be reconsidered.
> 
> I think part of the problem is the fact that Java does not have a good
> way of marking an API as experimental. Anything public can never
> change, so JDK developers don't make things public if they are not
> quite happy with the API yet, even though some bits would be useful
> for others. As a consequence, they get no or very little feedback on a
> private API, thus slowing the progress towards the non-experimental
> API even more. Sure, experimental functionality could still be dropped
> at any time, but that is not happening here. The functionality
> remains, it is just going to be hidden.
> 
> Robert makes a good point that designing a stable API for something
> that is currently private and possibly ugly is much more work than
> pulling ad-hoc hacks with the experimental API. I believe Jira issues
> are mostly there, I'm just skeptical that all of the issues currently
> targeted for 9 will actually be resolved in 9.
> 
>> On Wed, Apr 8, 2015 at 1:23 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>> OK, while I wrote this, all the other replies came in. So I see that your
>> recommendation for the cases I mentioned is then to patch OpenJDK and
>> submit Jira issues. Fair enough.
>> 
>> Regarding Jira issues, we are already doing that. Regarding code
>> contribution, this is a different thing, because in many cases a hack to
>> expose something that should be there is quick but designing a consistent
>> API that exposes the missing things is often something that requires a
>> different qualification.
>> 
>> 
>>> 

From snfuchs at gmx.de  Wed Apr  8 18:56:02 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Wed, 08 Apr 2015 20:56:02 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55255AE1.2070302@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com>
Message-ID: <552579C2.5020000@gmx.de>

Hi,

then I can only hope, that this flag is available to webstart applications.
Webstart applications have no control over the installed jre. In the 
past we encountered various bugs in the jre, which required using 
internal apis for workarounds.
For example in some releases of Java 7 the swing gui thread did not 
start unless hacking internal apis (see 
https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an 
error occurs again in the future and we are no longer able to hack 
around the problem, our only choice to keep our business alive, is to 
discourage users from upgrading to newer versions of the jre, exposing 
them to security risks.

- Stefan


>
> >  it's not strictly JFX-only.
>
> Its not remotely FX only, in fact I could argue FX is not so affected,
> as being relatively new it does not have 20 years of accumulation
> of people using internal APIs that the larger JDK does, often dating from
> when there were no suitable public APIs. There still remains some
> of that with sun.misc.Unsafe as pointed out which will indeed be
> inaccessible in modular mode. But the FX list isn't really the place
> for that discussion. The jigsaw-dev is the appropriate list. FX
> is simply bound by the rules that are set there.
>
> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
> transition.
>
> Also remember FX is open source. You can propose patches !
> If there are specific APIs that are missing from FX that are suitable
> to be *supported* public APIs then those could be considered here 
> (this list).
>
> -phil.
>
> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>> sed -i 's/private/public/g' ;)
>>
>> The whole notion of a strongly enforced private keyword is IMHO dumb 
>> when
>> not using sandboxing. The number of gross hacks that occur in an 
>> attempt to
>> work around overly strict enforcement of this stuff is crazy. The D
>> compiler has a special flag that disables visibility enforcement when
>> compiling unit tests, and that's a good idea, but why not go all the way
>> and just make accessing of private state a compiler warning a la 
>> deprecated?
>>
>> I also need to use private JFX APIs. I think any real JFX app does, 
>> way too
>> much basic stuff relies on it. Heck, the number of popular Java 
>> libraries
>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
>> back in
>> this regard then I will just write a simple tool that flips 
>> private->public
>> either at the source level or via bytecode editing, and see what 
>> happens :-)
>>
>>
>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> 
>> wrote:
>>
>>> Hi,
>>>
>>> I hope this is not too off-topic, because although it came up in a JFX
>>> context it's not strictly JFX-only.
>>>
>>> Someone from our team recently had a chat with a high-ranking regional
>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>> explained our situation (evaluating JFX to migrate our swing-based 
>>> product,
>>> feeling it's in principle the right technology but still having
>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>> relay our concrete questions to the right people, which he did.
>>>
>>> The answer we got contained one thing that really was a bit of a 
>>> shock and
>>> I would like someone to either confirm this or clear up a 
>>> misunderstanding.
>>>
>>> The statement was that private APIs will not be available in JDK 9 
>>> due to
>>> modularity restrictions. If that is the case and we no longer have the
>>> ability to build temporary workarounds using private APIs (which in our
>>> case is controllable as we ship the JRE with our product), I would 
>>> probably
>>> have to stop any development going into the direction of JFX as we will
>>> probably have to use 9 at some point because many things now 
>>> scheduled for
>>> 9 will not get fixed in 8 and we will most likely still need 
>>> workarounds
>>> using private API, at least that's what my current experience with JFX
>>> tells me.
>>>
>>> Please tell me that this was a misunderstanding (maybe meant for the
>>> general case where one does not ship the JRE) or a non-engineering 
>>> source
>>> that simply made mistake.
>>>
>>> Best regards and thanks in advance,
>>>
>>> Robert
>>>
>
>


From donald.smith at oracle.com  Wed Apr  8 19:15:42 2015
From: donald.smith at oracle.com (Donald Smith)
Date: Wed, 08 Apr 2015 15:15:42 -0400
Subject: Private APIs not usable in Java 9?
In-Reply-To: <552579C2.5020000@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>
	<552579C2.5020000@gmx.de>
Message-ID: <55257E5E.9010304@oracle.com>

Making any theoretical flag available to the deployment side would 
entirely miss the point.

Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait 
for it -- Unsafe.  It must go.  Ignore any kind of theoretical rope and 
start the path to righteousness _*/now/*_. It is still years until the 
end of public updates to JDK 8, so we have /*years */to work this out 
properly.  But sticking our heads in the collective sands and hoping for 
trivial work arounds to Unsafe is not going to work.  If you're using 
Unsafe, this is the year to explain where the API is broken and get it 
straight....

Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do 
so as quickly as possible to the ultimate benefit of everyone.

  - Don

On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
> Hi,
>
> then I can only hope, that this flag is available to webstart 
> applications.
> Webstart applications have no control over the installed jre. In the 
> past we encountered various bugs in the jre, which required using 
> internal apis for workarounds.
> For example in some releases of Java 7 the swing gui thread did not 
> start unless hacking internal apis (see 
> https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an 
> error occurs again in the future and we are no longer able to hack 
> around the problem, our only choice to keep our business alive, is to 
> discourage users from upgrading to newer versions of the jre, exposing 
> them to security risks.
>
> - Stefan
>
>
>>
>> >  it's not strictly JFX-only.
>>
>> Its not remotely FX only, in fact I could argue FX is not so affected,
>> as being relatively new it does not have 20 years of accumulation
>> of people using internal APIs that the larger JDK does, often dating 
>> from
>> when there were no suitable public APIs. There still remains some
>> of that with sun.misc.Unsafe as pointed out which will indeed be
>> inaccessible in modular mode. But the FX list isn't really the place
>> for that discussion. The jigsaw-dev is the appropriate list. FX
>> is simply bound by the rules that are set there.
>>
>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
>> transition.
>>
>> Also remember FX is open source. You can propose patches !
>> If there are specific APIs that are missing from FX that are suitable
>> to be *supported* public APIs then those could be considered here 
>> (this list).
>>
>> -phil.
>>
>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>> sed -i 's/private/public/g' ;)
>>>
>>> The whole notion of a strongly enforced private keyword is IMHO dumb 
>>> when
>>> not using sandboxing. The number of gross hacks that occur in an 
>>> attempt to
>>> work around overly strict enforcement of this stuff is crazy. The D
>>> compiler has a special flag that disables visibility enforcement when
>>> compiling unit tests, and that's a good idea, but why not go all the 
>>> way
>>> and just make accessing of private state a compiler warning a la 
>>> deprecated?
>>>
>>> I also need to use private JFX APIs. I think any real JFX app does, 
>>> way too
>>> much basic stuff relies on it. Heck, the number of popular Java 
>>> libraries
>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
>>> back in
>>> this regard then I will just write a simple tool that flips 
>>> private->public
>>> either at the source level or via bytecode editing, and see what 
>>> happens :-)
>>>
>>>
>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>> context it's not strictly JFX-only.
>>>>
>>>> Someone from our team recently had a chat with a high-ranking regional
>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>> explained our situation (evaluating JFX to migrate our swing-based 
>>>> product,
>>>> feeling it's in principle the right technology but still having
>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>> relay our concrete questions to the right people, which he did.
>>>>
>>>> The answer we got contained one thing that really was a bit of a 
>>>> shock and
>>>> I would like someone to either confirm this or clear up a 
>>>> misunderstanding.
>>>>
>>>> The statement was that private APIs will not be available in JDK 9 
>>>> due to
>>>> modularity restrictions. If that is the case and we no longer have the
>>>> ability to build temporary workarounds using private APIs (which in 
>>>> our
>>>> case is controllable as we ship the JRE with our product), I would 
>>>> probably
>>>> have to stop any development going into the direction of JFX as we 
>>>> will
>>>> probably have to use 9 at some point because many things now 
>>>> scheduled for
>>>> 9 will not get fixed in 8 and we will most likely still need 
>>>> workarounds
>>>> using private API, at least that's what my current experience with JFX
>>>> tells me.
>>>>
>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>> general case where one does not ship the JRE) or a non-engineering 
>>>> source
>>>> that simply made mistake.
>>>>
>>>> Best regards and thanks in advance,
>>>>
>>>> Robert
>>>>
>>
>>
>


From snfuchs at gmx.de  Wed Apr  8 19:21:17 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Wed, 08 Apr 2015 21:21:17 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55257E5E.9010304@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>	<552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com>
Message-ID: <55257FAD.9040308@gmx.de>

Hi,

you are right, there are still years to the end of public updates to JDK 
8....   We can use them to migrate to other technologies.

- Stefan


> Making any theoretical flag available to the deployment side would 
> entirely miss the point.
>
> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait 
> for it -- Unsafe.  It must go.  Ignore any kind of theoretical rope 
> and start the path to righteousness _*/now/*_. It is still years until 
> the end of public updates to JDK 8, so we have /*years */to work this 
> out properly.  But sticking our heads in the collective sands and 
> hoping for trivial work arounds to Unsafe is not going to work.  If 
> you're using Unsafe, this is the year to explain where the API is 
> broken and get it straight....
>
> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and 
> do so as quickly as possible to the ultimate benefit of everyone.
>
>  - Don
>
> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>> Hi,
>>
>> then I can only hope, that this flag is available to webstart 
>> applications.
>> Webstart applications have no control over the installed jre. In the 
>> past we encountered various bugs in the jre, which required using 
>> internal apis for workarounds.
>> For example in some releases of Java 7 the swing gui thread did not 
>> start unless hacking internal apis (see 
>> https://javafx-jira.kenai.com/browse/RT-31205 for details). If such 
>> an error occurs again in the future and we are no longer able to hack 
>> around the problem, our only choice to keep our business alive, is to 
>> discourage users from upgrading to newer versions of the jre, 
>> exposing them to security risks.
>>
>> - Stefan
>>
>>
>>>
>>> >  it's not strictly JFX-only.
>>>
>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>> as being relatively new it does not have 20 years of accumulation
>>> of people using internal APIs that the larger JDK does, often dating 
>>> from
>>> when there were no suitable public APIs. There still remains some
>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>> inaccessible in modular mode. But the FX list isn't really the place
>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>> is simply bound by the rules that are set there.
>>>
>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the 
>>> transition.
>>>
>>> Also remember FX is open source. You can propose patches !
>>> If there are specific APIs that are missing from FX that are suitable
>>> to be *supported* public APIs then those could be considered here 
>>> (this list).
>>>
>>> -phil.
>>>
>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>> sed -i 's/private/public/g' ;)
>>>>
>>>> The whole notion of a strongly enforced private keyword is IMHO 
>>>> dumb when
>>>> not using sandboxing. The number of gross hacks that occur in an 
>>>> attempt to
>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>> compiler has a special flag that disables visibility enforcement when
>>>> compiling unit tests, and that's a good idea, but why not go all 
>>>> the way
>>>> and just make accessing of private state a compiler warning a la 
>>>> deprecated?
>>>>
>>>> I also need to use private JFX APIs. I think any real JFX app does, 
>>>> way too
>>>> much basic stuff relies on it. Heck, the number of popular Java 
>>>> libraries
>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
>>>> back in
>>>> this regard then I will just write a simple tool that flips 
>>>> private->public
>>>> either at the source level or via bytecode editing, and see what 
>>>> happens :-)
>>>>
>>>>
>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de> 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I hope this is not too off-topic, because although it came up in a 
>>>>> JFX
>>>>> context it's not strictly JFX-only.
>>>>>
>>>>> Someone from our team recently had a chat with a high-ranking 
>>>>> regional
>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>> explained our situation (evaluating JFX to migrate our swing-based 
>>>>> product,
>>>>> feeling it's in principle the right technology but still having
>>>>> show-stopping limitations like RT-36215) and the Oracle guy 
>>>>> offered to
>>>>> relay our concrete questions to the right people, which he did.
>>>>>
>>>>> The answer we got contained one thing that really was a bit of a 
>>>>> shock and
>>>>> I would like someone to either confirm this or clear up a 
>>>>> misunderstanding.
>>>>>
>>>>> The statement was that private APIs will not be available in JDK 9 
>>>>> due to
>>>>> modularity restrictions. If that is the case and we no longer have 
>>>>> the
>>>>> ability to build temporary workarounds using private APIs (which 
>>>>> in our
>>>>> case is controllable as we ship the JRE with our product), I would 
>>>>> probably
>>>>> have to stop any development going into the direction of JFX as we 
>>>>> will
>>>>> probably have to use 9 at some point because many things now 
>>>>> scheduled for
>>>>> 9 will not get fixed in 8 and we will most likely still need 
>>>>> workarounds
>>>>> using private API, at least that's what my current experience with 
>>>>> JFX
>>>>> tells me.
>>>>>
>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>> general case where one does not ship the JRE) or a non-engineering 
>>>>> source
>>>>> that simply made mistake.
>>>>>
>>>>> Best regards and thanks in advance,
>>>>>
>>>>> Robert
>>>>>
>>>
>>>
>>
>
>


From tomas.mikula at gmail.com  Wed Apr  8 19:51:57 2015
From: tomas.mikula at gmail.com (Tomas Mikula)
Date: Wed, 8 Apr 2015 15:51:57 -0400
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55257E5E.9010304@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com>
Message-ID: <CA+THruoZiOSN2AFXNdaNeRXd56igu5KK4niPboEek0-2s8Ep=g@mail.gmail.com>

I do believe in making things right (like killing Unsafe, hiding private APIs).

The transition will just be so much pain now that there is so much
accumulated private APIs used in production. If there were no
accessible private APIs to start with, there would be more pressure to
fix bugs and expose functionality in public APIs.

And no, in practice, there are not /*years*/ to transition. In
practice, projects have dependencies. If I decide to move on to 9, but
my dependency has not been ported yet, I have a problem. If I'm still
stuck with 8, but my dependency has moved on to 9 and stopped
backporting bugfixes and new features to 8 (which would be
understandable, because it is quite a bit of maintanence cost to
maintain two codebases), then I have a problem.

Anyway, the transition is inevitable and good in the long term. I will
just be happy if Oracle manages to flesh out their experimental
private APIs that people are already using today, but I am somewhat
skeptical that this will happen for JavaFX before 9, thus resulting in
a period of temporarily lost functionality.

Tomas

On Wed, Apr 8, 2015 at 3:15 PM, Donald Smith <donald.smith at oracle.com> wrote:
> Making any theoretical flag available to the deployment side would entirely
> miss the point.
>
> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait for it
> -- Unsafe.  It must go.  Ignore any kind of theoretical rope and start the
> path to righteousness _*/now/*_. It is still years until the end of public
> updates to JDK 8, so we have /*years */to work this out properly.  But
> sticking our heads in the collective sands and hoping for trivial work
> arounds to Unsafe is not going to work.  If you're using Unsafe, this is the
> year to explain where the API is broken and get it straight....
>
> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so
> as quickly as possible to the ultimate benefit of everyone.
>
>  - Don
>
>
> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>
>> Hi,
>>
>> then I can only hope, that this flag is available to webstart
>> applications.
>> Webstart applications have no control over the installed jre. In the past
>> we encountered various bugs in the jre, which required using internal apis
>> for workarounds.
>> For example in some releases of Java 7 the swing gui thread did not start
>> unless hacking internal apis (see
>> https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error
>> occurs again in the future and we are no longer able to hack around the
>> problem, our only choice to keep our business alive, is to discourage users
>> from upgrading to newer versions of the jre, exposing them to security
>> risks.
>>
>> - Stefan
>>
>>
>>>
>>> >  it's not strictly JFX-only.
>>>
>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>> as being relatively new it does not have 20 years of accumulation
>>> of people using internal APIs that the larger JDK does, often dating from
>>> when there were no suitable public APIs. There still remains some
>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>> inaccessible in modular mode. But the FX list isn't really the place
>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>> is simply bound by the rules that are set there.
>>>
>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>> transition.
>>>
>>> Also remember FX is open source. You can propose patches !
>>> If there are specific APIs that are missing from FX that are suitable
>>> to be *supported* public APIs then those could be considered here (this
>>> list).
>>>
>>> -phil.
>>>
>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>>
>>>> sed -i 's/private/public/g' ;)
>>>>
>>>> The whole notion of a strongly enforced private keyword is IMHO dumb
>>>> when
>>>> not using sandboxing. The number of gross hacks that occur in an attempt
>>>> to
>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>> compiler has a special flag that disables visibility enforcement when
>>>> compiling unit tests, and that's a good idea, but why not go all the way
>>>> and just make accessing of private state a compiler warning a la
>>>> deprecated?
>>>>
>>>> I also need to use private JFX APIs. I think any real JFX app does, way
>>>> too
>>>> much basic stuff relies on it. Heck, the number of popular Java
>>>> libraries
>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
>>>> in
>>>> this regard then I will just write a simple tool that flips
>>>> private->public
>>>> either at the source level or via bytecode editing, and see what happens
>>>> :-)
>>>>
>>>>
>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>>> context it's not strictly JFX-only.
>>>>>
>>>>> Someone from our team recently had a chat with a high-ranking regional
>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>>> product,
>>>>> feeling it's in principle the right technology but still having
>>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>>> relay our concrete questions to the right people, which he did.
>>>>>
>>>>> The answer we got contained one thing that really was a bit of a shock
>>>>> and
>>>>> I would like someone to either confirm this or clear up a
>>>>> misunderstanding.
>>>>>
>>>>> The statement was that private APIs will not be available in JDK 9 due
>>>>> to
>>>>> modularity restrictions. If that is the case and we no longer have the
>>>>> ability to build temporary workarounds using private APIs (which in our
>>>>> case is controllable as we ship the JRE with our product), I would
>>>>> probably
>>>>> have to stop any development going into the direction of JFX as we will
>>>>> probably have to use 9 at some point because many things now scheduled
>>>>> for
>>>>> 9 will not get fixed in 8 and we will most likely still need
>>>>> workarounds
>>>>> using private API, at least that's what my current experience with JFX
>>>>> tells me.
>>>>>
>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>> general case where one does not ship the JRE) or a non-engineering
>>>>> source
>>>>> that simply made mistake.
>>>>>
>>>>> Best regards and thanks in advance,
>>>>>
>>>>> Robert
>>>>>
>>>
>>>
>>
>

From krueger at lesspain.de  Wed Apr  8 19:52:42 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 8 Apr 2015 21:52:42 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55257FAD.9040308@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
Message-ID: <CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>

exactly. I don't give a **** about Unsafe but I have to deal with the
realities of Java(FX) in its current state and as long as bugs or
limitations that simply make it impossible to ship a product that can
compete with others in our market sit there for months or years and our
only workaround is to use private API and that is taken away then we only
have the choice to move to another technology, which we do not really want
to do. Luckily we are in a better position than Stefan still being able to
modify the JRE in those emergencies but I absolutely see his point.

Your point about Java 8 being available for a long time is moot in a JFX
context as we all know that JFX is very much in motion and needs to be,
because it is far from mature. _All_ of my 6 open issues in Jira plus some
others I am watching because we have run tinto them as well haven been
scheduled for Java 9. _All_ of them are either serious problems or even
showstoppers for products of ours. Should I rely now on all of those fixes
to be backported to 8?


On Wed, Apr 8, 2015 at 9:21 PM, Stefan Fuchs <snfuchs at gmx.de> wrote:

> Hi,
>
> you are right, there are still years to the end of public updates to JDK
> 8....   We can use them to migrate to other technologies.
>
> - Stefan
>
>
>
>  Making any theoretical flag available to the deployment side would
>> entirely miss the point.
>>
>> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait for
>> it -- Unsafe.  It must go.  Ignore any kind of theoretical rope and start
>> the path to righteousness _*/now/*_. It is still years until the end of
>> public updates to JDK 8, so we have /*years */to work this out properly.
>> But sticking our heads in the collective sands and hoping for trivial work
>> arounds to Unsafe is not going to work.  If you're using Unsafe, this is
>> the year to explain where the API is broken and get it straight....
>>
>> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do
>> so as quickly as possible to the ultimate benefit of everyone.
>>
>>  - Don
>>
>> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>
>>> Hi,
>>>
>>> then I can only hope, that this flag is available to webstart
>>> applications.
>>> Webstart applications have no control over the installed jre. In the
>>> past we encountered various bugs in the jre, which required using internal
>>> apis for workarounds.
>>> For example in some releases of Java 7 the swing gui thread did not
>>> start unless hacking internal apis (see https://javafx-jira.kenai.com/
>>> browse/RT-31205 for details). If such an error occurs again in the
>>> future and we are no longer able to hack around the problem, our only
>>> choice to keep our business alive, is to discourage users from upgrading to
>>> newer versions of the jre, exposing them to security risks.
>>>
>>> - Stefan
>>>
>>>
>>>
>>>> >  it's not strictly JFX-only.
>>>>
>>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>>> as being relatively new it does not have 20 years of accumulation
>>>> of people using internal APIs that the larger JDK does, often dating
>>>> from
>>>> when there were no suitable public APIs. There still remains some
>>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>>> inaccessible in modular mode. But the FX list isn't really the place
>>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>>> is simply bound by the rules that are set there.
>>>>
>>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>>> transition.
>>>>
>>>> Also remember FX is open source. You can propose patches !
>>>> If there are specific APIs that are missing from FX that are suitable
>>>> to be *supported* public APIs then those could be considered here (this
>>>> list).
>>>>
>>>> -phil.
>>>>
>>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>>
>>>>> sed -i 's/private/public/g' ;)
>>>>>
>>>>> The whole notion of a strongly enforced private keyword is IMHO dumb
>>>>> when
>>>>> not using sandboxing. The number of gross hacks that occur in an
>>>>> attempt to
>>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>>> compiler has a special flag that disables visibility enforcement when
>>>>> compiling unit tests, and that's a good idea, but why not go all the
>>>>> way
>>>>> and just make accessing of private state a compiler warning a la
>>>>> deprecated?
>>>>>
>>>>> I also need to use private JFX APIs. I think any real JFX app does,
>>>>> way too
>>>>> much basic stuff relies on it. Heck, the number of popular Java
>>>>> libraries
>>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
>>>>> in
>>>>> this regard then I will just write a simple tool that flips
>>>>> private->public
>>>>> either at the source level or via bytecode editing, and see what
>>>>> happens :-)
>>>>>
>>>>>
>>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>>>>> wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>>>> context it's not strictly JFX-only.
>>>>>>
>>>>>> Someone from our team recently had a chat with a high-ranking regional
>>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>>>> product,
>>>>>> feeling it's in principle the right technology but still having
>>>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>>>> relay our concrete questions to the right people, which he did.
>>>>>>
>>>>>> The answer we got contained one thing that really was a bit of a
>>>>>> shock and
>>>>>> I would like someone to either confirm this or clear up a
>>>>>> misunderstanding.
>>>>>>
>>>>>> The statement was that private APIs will not be available in JDK 9
>>>>>> due to
>>>>>> modularity restrictions. If that is the case and we no longer have the
>>>>>> ability to build temporary workarounds using private APIs (which in
>>>>>> our
>>>>>> case is controllable as we ship the JRE with our product), I would
>>>>>> probably
>>>>>> have to stop any development going into the direction of JFX as we
>>>>>> will
>>>>>> probably have to use 9 at some point because many things now
>>>>>> scheduled for
>>>>>> 9 will not get fixed in 8 and we will most likely still need
>>>>>> workarounds
>>>>>> using private API, at least that's what my current experience with JFX
>>>>>> tells me.
>>>>>>
>>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>>> general case where one does not ship the JRE) or a non-engineering
>>>>>> source
>>>>>> that simply made mistake.
>>>>>>
>>>>>> Best regards and thanks in advance,
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Robert Kr?ger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

From tomas.mikula at gmail.com  Wed Apr  8 19:59:43 2015
From: tomas.mikula at gmail.com (Tomas Mikula)
Date: Wed, 8 Apr 2015 15:59:43 -0400
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
Message-ID: <CA+THrurV15bE63KxNA+jt-qkYR2D8B5aopxe2D7TfgtGSSVYZA@mail.gmail.com>

>Should I rely now on all of those fixes
> to be backported to 8?

Why do you need them to be backported to 8? Just having them fixed in
9 should be fine, no? (keeping the private workarounds for 8)

T.

From danno.ferrin at oracle.com  Wed Apr  8 20:05:36 2015
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Wed, 8 Apr 2015 14:05:36 -0600
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
Message-ID: <74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>


> On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>  our only workaround is to use private API 

For the benefit of the devs on the list, could you please point out what private APIs you currently need to use?  That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.

From herve.girod at gmail.com  Wed Apr  8 20:24:03 2015
From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=)
Date: Wed, 8 Apr 2015 22:24:03 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
Message-ID: <8F58AA4C-D136-4C6B-8AC7-B88E4D659CF2@gmail.com>

Do you need a specific classification for such JIRAs?

Sent from my iPhone

> On Apr 8, 2015, at 22:05, Danno Ferrin <danno.ferrin at oracle.com> wrote:
> 
> 
>> On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>> our only workaround is to use private API
> 
> For the benefit of the devs on the list, could you please point out what private APIs you currently need to use?  That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.

From danno.ferrin at oracle.com  Wed Apr  8 20:26:29 2015
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Wed, 8 Apr 2015 14:26:29 -0600
Subject: Private APIs not usable in Java 9?
In-Reply-To: <8F58AA4C-D136-4C6B-8AC7-B88E4D659CF2@gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
	<8F58AA4C-D136-4C6B-8AC7-B88E4D659CF2@gmail.com>
Message-ID: <E4646C1E-032E-4E8C-89DA-0416C621C97C@oracle.com>

Just adding to the comment that a specific user has the issue will help, especially when it comes to validating the fix.

> On Apr 8, 2015, at 2:24 PM, Herv? Girod <herve.girod at gmail.com> wrote:
> 
> Do you need a specific classification for such JIRAs?
> 
> Sent from my iPhone
> 
>> On Apr 8, 2015, at 22:05, Danno Ferrin <danno.ferrin at oracle.com> wrote:
>> 
>> 
>>> On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>>> our only workaround is to use private API
>> 
>> For the benefit of the devs on the list, could you please point out what private APIs you currently need to use?  That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.


From snfuchs at gmx.de  Wed Apr  8 21:03:20 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Wed, 08 Apr 2015 23:03:20 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55257FAD.9040308@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>	<552579C2.5020000@gmx.de>	<55257E5E.9010304@oracle.com>
	<55257FAD.9040308@gmx.de>
Message-ID: <55259798.80803@gmx.de>

Hi,

and one more thing, I don't care about Unsafe. It can die unless it is 
involved in a workaround for the StringIndexOutOfBoundsException in 
CertUtils.checkWildcardDomain we currently see in java 8u60-ea when 
opening an https connection to our servers. Hopefully this can be fixed 
till the final release.

But in all artificial restrictions to implement your own workarounds 
using private apis its another minus on our assessment of the risks 
involved, when investing in the javafx technology. Others are the 
diminishing plugin support by browser vendors and a lack of commitment 
from oracle for growing platforms like android or ios.
On the other side of the equation is unrestricted access of the 
application to the local filesystem and cpu resources and the rich java 
apis.

Currently the equation still holds in favor of javafx, but is constantly 
evaluated.

And as you can see at http://easyprint.com we currently use different 
technologies for the online editors of our print products. Still adobe 
flash for the simple products (Print products and Textile products) and 
an new JavaFX based editor in the same design as the flash editor for 
the more complex photo products. So an html5 editor could certainly 
become the successor of the javafx editor.

Anyway I think especially for webstart applications, which have no 
control over the installed jre should have the possibility to access 
private apis. If a installed application can do it, why shouldn't the 
same be possible for a webstart application?

<evil grin>
Or perhaps, as it has full access to the filesystem, my application 
could start patching class files in the installed jre....
</evil grin>

No, I don't think that would be a good idea.


- Stefan


> Hi,
>
> you are right, there are still years to the end of public updates to 
> JDK 8....   We can use them to migrate to other technologies.
>
> - Stefan
>
>
>> Making any theoretical flag available to the deployment side would 
>> entirely miss the point.
>>
>> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait 
>> for it -- Unsafe.  It must go.  Ignore any kind of theoretical rope 
>> and start the path to righteousness _*/now/*_. It is still years 
>> until the end of public updates to JDK 8, so we have /*years */to 
>> work this out properly.  But sticking our heads in the collective 
>> sands and hoping for trivial work arounds to Unsafe is not going to 
>> work.  If you're using Unsafe, this is the year to explain where the 
>> API is broken and get it straight....
>>
>> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and 
>> do so as quickly as possible to the ultimate benefit of everyone.
>>
>>  - Don
>>
>> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>> Hi,
>>>
>>> then I can only hope, that this flag is available to webstart 
>>> applications.
>>> Webstart applications have no control over the installed jre. In the 
>>> past we encountered various bugs in the jre, which required using 
>>> internal apis for workarounds.
>>> For example in some releases of Java 7 the swing gui thread did not 
>>> start unless hacking internal apis (see 
>>> https://javafx-jira.kenai.com/browse/RT-31205 for details). If such 
>>> an error occurs again in the future and we are no longer able to 
>>> hack around the problem, our only choice to keep our business alive, 
>>> is to discourage users from upgrading to newer versions of the jre, 
>>> exposing them to security risks.
>>>
>>> - Stefan
>>>
>>>
>>>>
>>>> >  it's not strictly JFX-only.
>>>>
>>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>>> as being relatively new it does not have 20 years of accumulation
>>>> of people using internal APIs that the larger JDK does, often 
>>>> dating from
>>>> when there were no suitable public APIs. There still remains some
>>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>>> inaccessible in modular mode. But the FX list isn't really the place
>>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>>> is simply bound by the rules that are set there.
>>>>
>>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in 
>>>> the transition.
>>>>
>>>> Also remember FX is open source. You can propose patches !
>>>> If there are specific APIs that are missing from FX that are suitable
>>>> to be *supported* public APIs then those could be considered here 
>>>> (this list).
>>>>
>>>> -phil.
>>>>
>>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>>> sed -i 's/private/public/g' ;)
>>>>>
>>>>> The whole notion of a strongly enforced private keyword is IMHO 
>>>>> dumb when
>>>>> not using sandboxing. The number of gross hacks that occur in an 
>>>>> attempt to
>>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>>> compiler has a special flag that disables visibility enforcement when
>>>>> compiling unit tests, and that's a good idea, but why not go all 
>>>>> the way
>>>>> and just make accessing of private state a compiler warning a la 
>>>>> deprecated?
>>>>>
>>>>> I also need to use private JFX APIs. I think any real JFX app 
>>>>> does, way too
>>>>> much basic stuff relies on it. Heck, the number of popular Java 
>>>>> libraries
>>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the 
>>>>> back in
>>>>> this regard then I will just write a simple tool that flips 
>>>>> private->public
>>>>> either at the source level or via bytecode editing, and see what 
>>>>> happens :-)
>>>>>
>>>>>
>>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger 
>>>>> <krueger at lesspain.de> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I hope this is not too off-topic, because although it came up in 
>>>>>> a JFX
>>>>>> context it's not strictly JFX-only.
>>>>>>
>>>>>> Someone from our team recently had a chat with a high-ranking 
>>>>>> regional
>>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>>> explained our situation (evaluating JFX to migrate our 
>>>>>> swing-based product,
>>>>>> feeling it's in principle the right technology but still having
>>>>>> show-stopping limitations like RT-36215) and the Oracle guy 
>>>>>> offered to
>>>>>> relay our concrete questions to the right people, which he did.
>>>>>>
>>>>>> The answer we got contained one thing that really was a bit of a 
>>>>>> shock and
>>>>>> I would like someone to either confirm this or clear up a 
>>>>>> misunderstanding.
>>>>>>
>>>>>> The statement was that private APIs will not be available in JDK 
>>>>>> 9 due to
>>>>>> modularity restrictions. If that is the case and we no longer 
>>>>>> have the
>>>>>> ability to build temporary workarounds using private APIs (which 
>>>>>> in our
>>>>>> case is controllable as we ship the JRE with our product), I 
>>>>>> would probably
>>>>>> have to stop any development going into the direction of JFX as 
>>>>>> we will
>>>>>> probably have to use 9 at some point because many things now 
>>>>>> scheduled for
>>>>>> 9 will not get fixed in 8 and we will most likely still need 
>>>>>> workarounds
>>>>>> using private API, at least that's what my current experience 
>>>>>> with JFX
>>>>>> tells me.
>>>>>>
>>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>>> general case where one does not ship the JRE) or a 
>>>>>> non-engineering source
>>>>>> that simply made mistake.
>>>>>>
>>>>>> Best regards and thanks in advance,
>>>>>>
>>>>>> Robert
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
>


From tbee at tbee.org  Wed Apr  8 21:12:36 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Wed, 08 Apr 2015 23:12:36 +0200
Subject: @import in CSS
Message-ID: <552599C4.8090608@tbee.org>

I'm currently porting and reworking some gauges from Enzo to JFXtras. One of things that gets reworked involves that all gauges will have custom colored segments. These segments can be preset using colorschemes (e.g. green to red in 10 steps), so the CSS for these colors are shared over all gauges. I tried using @import, but since it is required to be the first lines in a CSS, I'm suspecting that is the reason it is not working as expected.

Is there any intention to allow these imports to occur half way in a file? Placeholder-and-replace alike (#include), so to speak.

Tom

From snfuchs at gmx.de  Wed Apr  8 21:13:38 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Wed, 08 Apr 2015 23:13:38 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>
	<552579C2.5020000@gmx.de>	<55257E5E.9010304@oracle.com>
	<55257FAD.9040308@gmx.de>	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
Message-ID: <55259A02.2040902@gmx.de>

I' ll try to compile a list of the private apis we currently use in our 
application and why.

Looking forward to using only public apis in java 9 then :-)

- Stefan

>> On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>>   our only workaround is to use private API
> For the benefit of the devs on the list, could you please point out what private APIs you currently need to use?  That way we can make sure proper JIRAs are filed and we can connect those to actual real-world problems.


From david.grieve at oracle.com  Wed Apr  8 21:22:15 2015
From: david.grieve at oracle.com (David Grieve)
Date: Wed, 08 Apr 2015 17:22:15 -0400
Subject: @import in CSS
In-Reply-To: <552599C4.8090608@tbee.org>
References: <552599C4.8090608@tbee.org>
Message-ID: <55259C07.2020904@oracle.com>

The spec says that if there is an @import it has to appear first before 
any rule, except @charset, if present.

On 4/8/15 5:12 PM, Tom Eugelink wrote:
> I'm currently porting and reworking some gauges from Enzo to JFXtras. 
> One of things that gets reworked involves that all gauges will have 
> custom colored segments. These segments can be preset using 
> colorschemes (e.g. green to red in 10 steps), so the CSS for these 
> colors are shared over all gauges. I tried using @import, but since it 
> is required to be the first lines in a CSS, I'm suspecting that is the 
> reason it is not working as expected.
>
> Is there any intention to allow these imports to occur half way in a 
> file? Placeholder-and-replace alike (#include), so to speak.
>
> Tom


From mike at plan99.net  Wed Apr  8 22:41:12 2015
From: mike at plan99.net (Mike Hearn)
Date: Thu, 9 Apr 2015 00:41:12 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
Message-ID: <CANEZrP34mttVXwMHSXKYNN_=TBJ++FK4eBWu+QiY79YgxHOiWg@mail.gmail.com>

>
> For the benefit of the devs on the list, could you please point out what
> private APIs you currently need to use?  That way we can make sure proper
> JIRAs are filed and we can connect those to actual real-world problems.


e.g. handling a double click of a file on MacOS is impossible without using
private APIs currently. I think a bug is filed already, but I don't know
the number.

Learning if you're on the software pipeline or GL/D3D pipelines also
requires internal APIs. This is useful for winding back animations on
hardware/pipelines that can't take it.

Finding the current pixel scale of the screen, same.

I don't know if it counts but I find myself relying on or overriding
undocumented rules in modena.css somewhat frequently. For example the
edge-to-edge rule for ScrollPane. Of course, jigsaw will not break that.

I think AquaFX has to use internal APIs in various places though I don't
remember why.

Those are the examples from my (quite small) app.

From cnewland at chrisnewland.com  Wed Apr  8 22:48:38 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Wed, 8 Apr 2015 23:48:38 +0100
Subject: Canvas performance on Mac OS
In-Reply-To: <5524654C.2060500@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
Message-ID: <496230e5c8f0d2c725da8714f54b62d5.squirrel@excalibur.xssl.net>

Hi Jim,

Definitely discrete GPU on the iMac:

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

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

With software pipeline:

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

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

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

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

Cheers,

Chris


On Wed, April 8, 2015 00:16, Jim Graham wrote:
> OK, I took the time to put my rMBP on a diet yesterday and find room to
> install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
> so my theory that something changed in the OGL implementation for 10.10
> doesn't hold water.
>
> But, I then tried it using the integrated graphics.  I get really poor
> performance using the integrated Intel 4000 graphics, but I get great
> numbers on the discrete nVidia 650m.  It makes sense that the Intel
> graphics wouldn't be as powerful as the discrete graphics, but we
> shouldn't be taxing it that much to make that big of a difference.
>
> Just to be sure - is that iMac a dual graphics system, or is it
> all-AMD-all-the-time?  You can see which GPU is being used if you run it
> with -Dprism.verbose=true...
>
> ...jim
>
>
> On 4/2/15 4:13 PM, Jim Graham wrote:
>
>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>> running a newer version of MacOS?
>>
>> ...jim
>>
>>
>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>
>>> Hi Herv?,
>>>
>>>
>>> That's a valid question :)
>>>
>>>
>>> Probably because
>>>
>>>
>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>> systems
>>>
>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>> to go for that due to the very large number of nodes.
>>>
>>> Numbers for my Sierpinski filled triangle example:
>>>
>>>
>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>> 1024 MB
>>>
>>>
>>> java -Dprism.order=es2 -cp target/classes/
>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>> fps: 23
>>> fps: 18
>>> fps: 25
>>> fps: 18
>>> fps: 23
>>> fps: 23
>>> fps: 19
>>> fps: 25
>>>
>>>
>>> java -Dprism.order=sw -cp target/classes/
>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>> fps: 54
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>> fps: 60
>>>
>>>
>>> There are never more than 2500 filled triangles on screen. JDK is
>>> 1.8.0_40
>>>
>>>
>>> I would say there is a performance problem here? (or at least a need
>>> for documentation so as to set expectations for gc.fillPolygon).
>>>
>>> Best regards,
>>>
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>
>>>> Why don't you use Nodes rather than Canvas ?
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>>
>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>> <cnewland at chrisnewland.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi Jim,
>>>>>
>>>>>
>>>>>
>>>>> Thanks, that makes things much clearer.
>>>>>
>>>>>
>>>>>
>>>>> I was surprised how much was going on under the hood of
>>>>> GraphicsContext
>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>> acceleration where available and immediate-mode-like simple
>>>>> rasterizing where not.
>>>>>
>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>> so I expect suffers from the problem you've described.
>>>>>
>>>>> SSCCE:
>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>> com/ch
>>>>>
>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>
>>>>> Was full frame rate canvas drawing an expected use case for
>>>>> JavaFX or
>>>>> would I be better off with Graphics2D?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>> with a GPU
>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>> with an appropriate shader which is very fast.
>>>>>>
>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>> like:
>>>>>>
>>>>>>
>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>  drawLine() - dealing with only rendering common points of
>>>>>> intersection once
>>>>>>
>>>>>> To handle all of that complexity we have to involve a
>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>> mask for each pixel in the region. We do that in software
>>>>>> currently for all pipelines.
>>>>>>
>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>> CPU path
>>>>>> rasterization.
>>>>>>
>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>> dominates its performance.
>>>>>>
>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>> with drawLine() performance (as long as there are no additional
>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>
>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>> case. Does
>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>> SW
>>>>>> pipeline for the polygon case?
>>>>>>
>>>>>> One thing I noticed is that we have no optimized case for
>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>> rectangle and render it more directly.  If we added that support
>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>> calls faster than drawPolygon as well...
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>> I'd
>>>>>>> better add my findings.
>>>>>>>
>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>> strokeLine commands as expected:
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>> Result:
>>>>>>> 44fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>> Result:
>>>>>>> 60fps
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>  examples where ES2Pipeline performs horribly on my Mac which
>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>
>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>> JavaFX
>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>> do think there's a bug here.
>>>>>>>
>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>> slow" ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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(Op
>>>>>>>> en%2C% 20%2
>>>>>>>> 2In%
>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>> 20%20A
>>>>>>>> ND%2
>>>>>>>> 0la
>>>>>>>> bels%20in%20(performance)
>>>>>>>>
>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>> least OSX and Windows and
>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>
>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>> across diverse platforms"
>>>>>>>>
>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>> (8u40)
>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>  performance/quality problems on the Mac, I am a bit unsure
>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>> as far as dev resources are concerned?
>>>>>>>>
>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>> performance that can be tracked?
>>>>>>>>
>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>> the best.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Possibly related:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>> double y2) commands versus using a single
>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>> count) command.
>>>>>>>>>
>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>
>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>> benchmarking project I've created:
>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Build with ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Run with:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokeLine
>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokePolygon
>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>> result: 6 (six) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>> 20GB RAM
>>>>>>>>> /
>>>>>>>>> Radeon
>>>>>>>>> 6970M 1024MB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looking at the code paths in
>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>> than using the convenience method.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>> It is
>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>> Arcs
>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>  predetermined shader, but it shouldn't be that
>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>> be going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>> changes...
>>>>>>>>>>>>
>>>>>>>>>>>> ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>  AnimationTimer
>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>> (only
>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>  serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>> this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Kr??ger
>>>>>>>> Managing Partner
>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> www.lesspain-software.com
>>>>>
>>>>>
>>>>
>>>
>>>
>



From morris.meyer at oracle.com  Thu Apr  9 01:13:32 2015
From: morris.meyer at oracle.com (Morris Meyer)
Date: Wed, 08 Apr 2015 21:13:32 -0400
Subject: [8u-dev] Review request: [Windows] Ensemble 8: Spinner example layout
	is broken
Message-ID: <5525D23C.3060505@oracle.com>

Jonathan, Kevin and David,

Please review these layout changes to the Spinner Ensemble sample to 
proportionally layout the different Spinners.

Thanks much.

         --morris

JIRA - https://javafx-jira.kenai.com/browse/RT-40199
WEBREV - http://cr.openjdk.java.net/~morris/RT-40199.01/

From tom.schindl at bestsolution.at  Thu Apr  9 05:39:36 2015
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 09 Apr 2015 07:39:36 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55255AE1.2070302@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com>
Message-ID: <55261098.4030902@bestsolution.at>

Hi,

in SWT on JavaFX (most likely NOT a common useage of JavaFX):
-------------------------------------------------------------
I had to reside to private-API when it comes to:
* text calculations where there is no public API for things like
  FontMetrics, TextLayout, ...
* For some of the direct drawing code I had to use com.sun.javafx.geom.*
* For some operations I had to access the com.sun.glass.ui.Robot &
  com.sun.glass.ui.Application
* I had to get access to the VirtualFlow

To implement custom controls e.g. CodeEditor:
---------------------------------------------
* com.sun.javafx.scene.control.skin.BehaviorSkinBase
* com.sun.javafx.scene.control.behavior.KeyBinding
* com.sun.javafx.css.converters.InsetsConverter
* com.sun.javafx.css.converters.PaintConverter
* com.sun.javafx.scene.text.HitInfo

So to summerize the most lacking API is in the font/text rendering space
and to get public access to VirtualFlow would be a nice to have!

Tom


On 08.04.15 18:44, Phil Race wrote:
> 
>>  it's not strictly JFX-only.
> 
> Its not remotely FX only, in fact I could argue FX is not so affected,
> as being relatively new it does not have 20 years of accumulation
> of people using internal APIs that the larger JDK does, often dating from
> when there were no suitable public APIs. There still remains some
> of that with sun.misc.Unsafe as pointed out which will indeed be
> inaccessible in modular mode. But the FX list isn't really the place
> for that discussion. The jigsaw-dev is the appropriate list. FX
> is simply bound by the rules that are set there.
> 
> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> transition.
> 
> Also remember FX is open source. You can propose patches !
> If there are specific APIs that are missing from FX that are suitable
> to be *supported* public APIs then those could be considered here (this
> list).
> 
> -phil.
> 
> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>> sed -i 's/private/public/g' ;)
>>
>> The whole notion of a strongly enforced private keyword is IMHO dumb when
>> not using sandboxing. The number of gross hacks that occur in an
>> attempt to
>> work around overly strict enforcement of this stuff is crazy. The D
>> compiler has a special flag that disables visibility enforcement when
>> compiling unit tests, and that's a good idea, but why not go all the way
>> and just make accessing of private state a compiler warning a la
>> deprecated?
>>
>> I also need to use private JFX APIs. I think any real JFX app does,
>> way too
>> much basic stuff relies on it. Heck, the number of popular Java libraries
>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
>> this regard then I will just write a simple tool that flips
>> private->public
>> either at the source level or via bytecode editing, and see what
>> happens :-)
>>
>>
>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>> wrote:
>>
>>> Hi,
>>>
>>> I hope this is not too off-topic, because although it came up in a JFX
>>> context it's not strictly JFX-only.
>>>
>>> Someone from our team recently had a chat with a high-ranking regional
>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>> explained our situation (evaluating JFX to migrate our swing-based
>>> product,
>>> feeling it's in principle the right technology but still having
>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>> relay our concrete questions to the right people, which he did.
>>>
>>> The answer we got contained one thing that really was a bit of a
>>> shock and
>>> I would like someone to either confirm this or clear up a
>>> misunderstanding.
>>>
>>> The statement was that private APIs will not be available in JDK 9
>>> due to
>>> modularity restrictions. If that is the case and we no longer have the
>>> ability to build temporary workarounds using private APIs (which in our
>>> case is controllable as we ship the JRE with our product), I would
>>> probably
>>> have to stop any development going into the direction of JFX as we will
>>> probably have to use 9 at some point because many things now
>>> scheduled for
>>> 9 will not get fixed in 8 and we will most likely still need workarounds
>>> using private API, at least that's what my current experience with JFX
>>> tells me.
>>>
>>> Please tell me that this was a misunderstanding (maybe meant for the
>>> general case where one does not ship the JRE) or a non-engineering
>>> source
>>> that simply made mistake.
>>>
>>> Best regards and thanks in advance,
>>>
>>> Robert
>>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From tbee at tbee.org  Thu Apr  9 05:42:47 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Thu, 09 Apr 2015 07:42:47 +0200
Subject: @import in CSS
In-Reply-To: <55259C07.2020904@oracle.com>
References: <552599C4.8090608@tbee.org> <55259C07.2020904@oracle.com>
Message-ID: <55261157.9010402@tbee.org>

Does the order in which things appear in a CSS have influence on the behavior?

Tom


On 8-4-2015 23:22, David Grieve wrote:
> The spec says that if there is an @import it has to appear first before any rule, except @charset, if present.
>
> On 4/8/15 5:12 PM, Tom Eugelink wrote:
>> I'm currently porting and reworking some gauges from Enzo to JFXtras. One of things that gets reworked involves that all gauges will have custom colored segments. These segments can be preset using colorschemes (e.g. green to red in 10 steps), so the CSS for these colors are shared over all gauges. I tried using @import, but since it is required to be the first lines in a CSS, I'm suspecting that is the reason it is not working as expected.
>>
>> Is there any intention to allow these imports to occur half way in a file? Placeholder-and-replace alike (#include), so to speak.
>>
>> Tom
>


From krueger at lesspain.de  Thu Apr  9 05:49:42 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 9 Apr 2015 07:49:42 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
Message-ID: <CAEnqZEVJwy8jHxcWpz_WAJ5iLyjk6jUvu3O-MdVgZscEBdLjsQ@mail.gmail.com>

- Getting access to the native window to let our video player render into a
JFX screen, to have a video player with features and format support that
can compete with other players on the market (RT-36215), basically
following the example of Steve and Felipe's JavaOne presentation
"Integrating JavaFX with Native Technologies"
- Getting access to the currently displayed table rows by hacking into the
skin, because not being able to do so, would significantly degrade the UX
of our application (RT-39917). This will probably happen for other controls
(list, tree) in the future, when we dive in deeper because, as I understand
it, they share the same limitation.

Those two definitely so far but we have only started evaluating the porting
process and haven't had the time to check if things like RT-37372,
RT-37501, RT-40409 or RT-40379 can be worked around by using private APIs,
still hoping some of that will be fixed before we need to do something
about it ourselves.

On Wed, Apr 8, 2015 at 10:05 PM, Danno Ferrin <danno.ferrin at oracle.com>
wrote:

>
> > On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
> >  our only workaround is to use private API
>
> For the benefit of the devs on the list, could you please point out what
> private APIs you currently need to use?  That way we can make sure proper
> JIRAs are filed and we can connect those to actual real-world problems.




-- 
Robert Kr?ger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

From krueger at lesspain.de  Thu Apr  9 05:54:09 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 9 Apr 2015 07:54:09 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CA+THrurV15bE63KxNA+jt-qkYR2D8B5aopxe2D7TfgtGSSVYZA@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<CA+THrurV15bE63KxNA+jt-qkYR2D8B5aopxe2D7TfgtGSSVYZA@mail.gmail.com>
Message-ID: <CAEnqZEUvZwwPO_GBU_eWA6nMksiKOoUsxcNy5Gev+ExOvob-Kg@mail.gmail.com>

On Wed, Apr 8, 2015 at 9:59 PM, Tomas Mikula <tomas.mikula at gmail.com> wrote:

> >Should I rely now on all of those fixes
> > to be backported to 8?
>
> Why do you need them to be backported to 8? Just having them fixed in
> 9 should be fine, no? (keeping the private workarounds for 8)
>
> It was a response to the point that I could live with Java 8 for a few
more years if I needed private workarounds. Of course, in theory, if all of
them get fixed in 9 I am fine, but if there is a period of time where half
of them are fixed in 9 and the other half can only be worked around on 8,
what do I do with my product?

From krueger at lesspain.de  Thu Apr  9 06:02:39 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 9 Apr 2015 08:02:39 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55259798.80803@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <552579C2.5020000@gmx.de>
	<55257E5E.9010304@oracle.com> <55257FAD.9040308@gmx.de>
	<55259798.80803@gmx.de>
Message-ID: <CAEnqZEUpQR8jhY+4a9kJ1pzqFgccj+Nugr9=vH9uK0h1afQ+SQ@mail.gmail.com>

On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs <snfuchs at gmx.de> wrote:

>
> But in all artificial restrictions to implement your own workarounds using
> private apis its another minus on our assessment of the risks involved,
> when investing in the javafx technology. Others are the diminishing plugin
> support by browser vendors and a lack of commitment from oracle for growing
> platforms like android or ios.
> On the other side of the equation is unrestricted access of the
> application to the local filesystem and cpu resources and the rich java
> apis.
>
> Currently the equation still holds in favor of javafx, but is constantly
> evaluated.
>
>
*Exactly* the same situation here. I have been arguing against colleagues
proposing an approach where we keep the non-UI code Java and make the UI
using the native technologies similar to what robovm does for iOS APIs
which works remarkably well but of course has its drawbacks compared to
largely sharing the UI code across platforms but other obvious advantages.
With each of these decisions making it harder to somehow get through the
very long phase of JFX maturing, my case for porting to JFX falls apart
more and more.

From jonathan.giles at oracle.com  Thu Apr  9 07:53:58 2015
From: jonathan.giles at oracle.com (Jonathan Giles)
Date: Thu, 09 Apr 2015 19:53:58 +1200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55261098.4030902@bestsolution.at>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>
	<55261098.4030902@bestsolution.at>
Message-ID: <55263016.6090604@oracle.com>

For what it is worth, investigations are underway in relation to UI 
control skins and behaviors. It's too early for anything definitive to 
announce, but it is not inconceivable that 
com.sun.javafx.scene.control.skin may become javafx.scene.control.skin, 
more or less (with a lot of work cleaning up, etc).

In terms of behaviors, some investigations are already underway in 
RT-21598, but these too are only early, and fall under the bigger 
project of getting UI controls and CSS APIs into a jigsaw-friendly form 
for JDK 9 (which is a huge undertaking, and community support will be 
useful and sought at the appropriate time).

Thanks,

-- Jonathan

On 9/04/2015 5:39 p.m., Tom Schindl wrote:
> Hi,
>
> in SWT on JavaFX (most likely NOT a common useage of JavaFX):
> -------------------------------------------------------------
> I had to reside to private-API when it comes to:
> * text calculations where there is no public API for things like
>    FontMetrics, TextLayout, ...
> * For some of the direct drawing code I had to use com.sun.javafx.geom.*
> * For some operations I had to access the com.sun.glass.ui.Robot &
>    com.sun.glass.ui.Application
> * I had to get access to the VirtualFlow
>
> To implement custom controls e.g. CodeEditor:
> ---------------------------------------------
> * com.sun.javafx.scene.control.skin.BehaviorSkinBase
> * com.sun.javafx.scene.control.behavior.KeyBinding
> * com.sun.javafx.css.converters.InsetsConverter
> * com.sun.javafx.css.converters.PaintConverter
> * com.sun.javafx.scene.text.HitInfo
>
> So to summerize the most lacking API is in the font/text rendering space
> and to get public access to VirtualFlow would be a nice to have!
>
> Tom
>
>
> On 08.04.15 18:44, Phil Race wrote:
>>>   it's not strictly JFX-only.
>> Its not remotely FX only, in fact I could argue FX is not so affected,
>> as being relatively new it does not have 20 years of accumulation
>> of people using internal APIs that the larger JDK does, often dating from
>> when there were no suitable public APIs. There still remains some
>> of that with sun.misc.Unsafe as pointed out which will indeed be
>> inaccessible in modular mode. But the FX list isn't really the place
>> for that discussion. The jigsaw-dev is the appropriate list. FX
>> is simply bound by the rules that are set there.
>>
>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>> transition.
>>
>> Also remember FX is open source. You can propose patches !
>> If there are specific APIs that are missing from FX that are suitable
>> to be *supported* public APIs then those could be considered here (this
>> list).
>>
>> -phil.
>>
>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>> sed -i 's/private/public/g' ;)
>>>
>>> The whole notion of a strongly enforced private keyword is IMHO dumb when
>>> not using sandboxing. The number of gross hacks that occur in an
>>> attempt to
>>> work around overly strict enforcement of this stuff is crazy. The D
>>> compiler has a special flag that disables visibility enforcement when
>>> compiling unit tests, and that's a good idea, but why not go all the way
>>> and just make accessing of private state a compiler warning a la
>>> deprecated?
>>>
>>> I also need to use private JFX APIs. I think any real JFX app does,
>>> way too
>>> much basic stuff relies on it. Heck, the number of popular Java libraries
>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back in
>>> this regard then I will just write a simple tool that flips
>>> private->public
>>> either at the source level or via bytecode editing, and see what
>>> happens :-)
>>>
>>>
>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>> context it's not strictly JFX-only.
>>>>
>>>> Someone from our team recently had a chat with a high-ranking regional
>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>> product,
>>>> feeling it's in principle the right technology but still having
>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>> relay our concrete questions to the right people, which he did.
>>>>
>>>> The answer we got contained one thing that really was a bit of a
>>>> shock and
>>>> I would like someone to either confirm this or clear up a
>>>> misunderstanding.
>>>>
>>>> The statement was that private APIs will not be available in JDK 9
>>>> due to
>>>> modularity restrictions. If that is the case and we no longer have the
>>>> ability to build temporary workarounds using private APIs (which in our
>>>> case is controllable as we ship the JRE with our product), I would
>>>> probably
>>>> have to stop any development going into the direction of JFX as we will
>>>> probably have to use 9 at some point because many things now
>>>> scheduled for
>>>> 9 will not get fixed in 8 and we will most likely still need workarounds
>>>> using private API, at least that's what my current experience with JFX
>>>> tells me.
>>>>
>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>> general case where one does not ship the JRE) or a non-engineering
>>>> source
>>>> that simply made mistake.
>>>>
>>>> Best regards and thanks in advance,
>>>>
>>>> Robert
>>>>
>


From mike at plan99.net  Thu Apr  9 08:15:04 2015
From: mike at plan99.net (Mike Hearn)
Date: Thu, 9 Apr 2015 10:15:04 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55263016.6090604@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>
	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>
	<55255AE1.2070302@oracle.com> <55261098.4030902@bestsolution.at>
	<55263016.6090604@oracle.com>
Message-ID: <CANEZrP19u2jJf=ZjuzVc7Aq1Pvr=3vRUry9OjQtrrL80rNkNcA@mail.gmail.com>

I guess a good place to start would be to eliminate usage of private APIs
from scene builder. I understand that it doesn't seem to be supported any
more but it'd be extremely weird and embarrassing for Oracle if the UI
builder tool broke on Java 9 given all the work that went into it.
On 9 Apr 2015 9:54 am, "Jonathan Giles" <jonathan.giles at oracle.com> wrote:

> For what it is worth, investigations are underway in relation to UI
> control skins and behaviors. It's too early for anything definitive to
> announce, but it is not inconceivable that com.sun.javafx.scene.control.skin
> may become javafx.scene.control.skin, more or less (with a lot of work
> cleaning up, etc).
>
> In terms of behaviors, some investigations are already underway in
> RT-21598, but these too are only early, and fall under the bigger project
> of getting UI controls and CSS APIs into a jigsaw-friendly form for JDK 9
> (which is a huge undertaking, and community support will be useful and
> sought at the appropriate time).
>
> Thanks,
>
> -- Jonathan
>
> On 9/04/2015 5:39 p.m., Tom Schindl wrote:
>
>> Hi,
>>
>> in SWT on JavaFX (most likely NOT a common useage of JavaFX):
>> -------------------------------------------------------------
>> I had to reside to private-API when it comes to:
>> * text calculations where there is no public API for things like
>>    FontMetrics, TextLayout, ...
>> * For some of the direct drawing code I had to use com.sun.javafx.geom.*
>> * For some operations I had to access the com.sun.glass.ui.Robot &
>>    com.sun.glass.ui.Application
>> * I had to get access to the VirtualFlow
>>
>> To implement custom controls e.g. CodeEditor:
>> ---------------------------------------------
>> * com.sun.javafx.scene.control.skin.BehaviorSkinBase
>> * com.sun.javafx.scene.control.behavior.KeyBinding
>> * com.sun.javafx.css.converters.InsetsConverter
>> * com.sun.javafx.css.converters.PaintConverter
>> * com.sun.javafx.scene.text.HitInfo
>>
>> So to summerize the most lacking API is in the font/text rendering space
>> and to get public access to VirtualFlow would be a nice to have!
>>
>> Tom
>>
>>
>> On 08.04.15 18:44, Phil Race wrote:
>>
>>>   it's not strictly JFX-only.
>>>>
>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>> as being relatively new it does not have 20 years of accumulation
>>> of people using internal APIs that the larger JDK does, often dating from
>>> when there were no suitable public APIs. There still remains some
>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>> inaccessible in modular mode. But the FX list isn't really the place
>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>> is simply bound by the rules that are set there.
>>>
>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>> transition.
>>>
>>> Also remember FX is open source. You can propose patches !
>>> If there are specific APIs that are missing from FX that are suitable
>>> to be *supported* public APIs then those could be considered here (this
>>> list).
>>>
>>> -phil.
>>>
>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>
>>>> sed -i 's/private/public/g' ;)
>>>>
>>>> The whole notion of a strongly enforced private keyword is IMHO dumb
>>>> when
>>>> not using sandboxing. The number of gross hacks that occur in an
>>>> attempt to
>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>> compiler has a special flag that disables visibility enforcement when
>>>> compiling unit tests, and that's a good idea, but why not go all the way
>>>> and just make accessing of private state a compiler warning a la
>>>> deprecated?
>>>>
>>>> I also need to use private JFX APIs. I think any real JFX app does,
>>>> way too
>>>> much basic stuff relies on it. Heck, the number of popular Java
>>>> libraries
>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
>>>> in
>>>> this regard then I will just write a simple tool that flips
>>>> private->public
>>>> either at the source level or via bytecode editing, and see what
>>>> happens :-)
>>>>
>>>>
>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>>>> wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>>> context it's not strictly JFX-only.
>>>>>
>>>>> Someone from our team recently had a chat with a high-ranking regional
>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>>> product,
>>>>> feeling it's in principle the right technology but still having
>>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>>> relay our concrete questions to the right people, which he did.
>>>>>
>>>>> The answer we got contained one thing that really was a bit of a
>>>>> shock and
>>>>> I would like someone to either confirm this or clear up a
>>>>> misunderstanding.
>>>>>
>>>>> The statement was that private APIs will not be available in JDK 9
>>>>> due to
>>>>> modularity restrictions. If that is the case and we no longer have the
>>>>> ability to build temporary workarounds using private APIs (which in our
>>>>> case is controllable as we ship the JRE with our product), I would
>>>>> probably
>>>>> have to stop any development going into the direction of JFX as we will
>>>>> probably have to use 9 at some point because many things now
>>>>> scheduled for
>>>>> 9 will not get fixed in 8 and we will most likely still need
>>>>> workarounds
>>>>> using private API, at least that's what my current experience with JFX
>>>>> tells me.
>>>>>
>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>> general case where one does not ship the JRE) or a non-engineering
>>>>> source
>>>>> that simply made mistake.
>>>>>
>>>>> Best regards and thanks in advance,
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>
>

From dalibor.topic at oracle.com  Thu Apr  9 08:27:33 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 09 Apr 2015 10:27:33 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55259798.80803@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>	<552579C2.5020000@gmx.de>	<55257E5E.9010304@oracle.com>	<55257FAD.9040308@gmx.de>
	<55259798.80803@gmx.de>
Message-ID: <552637F5.5090005@oracle.com>



On 08.04.2015 23:03, Stefan Fuchs wrote:
> Anyway I think especially for webstart applications, which have no
> control over the installed jre should have the possibility to access
> private apis.

I would suggest reading http://openjdk.java.net/jeps/200 , 
http://openjdk.java.net/jeps/201 , http://openjdk.java.net/jeps/220 and 
then following the work of the JSR 376 expert group at 
http://openjdk.java.net/projects/jigsaw/spec/ , starting with 
http://openjdk.java.net/projects/jigsaw/spec/reqs/02 .

As previously suggested, a better place to discuss general technical 
aspects of Project Jigsaw would be the jigsaw-dev mailing list.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From anton.tarasov at oracle.com  Thu Apr  9 10:59:56 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 09 Apr 2015 13:59:56 +0300
Subject: [9] post-commit notification: RT-40271 Use application locale setting
	in WebView language header
Message-ID: <55265BAC.5020407@oracle.com>

JIRA: https://javafx-jira.kenai.com/browse/RT-40271
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ecf20572029f

Regards,
Anton.

From david.grieve at oracle.com  Thu Apr  9 11:34:39 2015
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 09 Apr 2015 07:34:39 -0400
Subject: @import in CSS
In-Reply-To: <55261157.9010402@tbee.org>
References: <552599C4.8090608@tbee.org> <55259C07.2020904@oracle.com>
	<55261157.9010402@tbee.org>
Message-ID: <552663CF.40805@oracle.com>

Yes. The details are in 
http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is the 
excerpt that matters: " if two declarations have the same weight, origin 
and specificity, the latter specified wins. Declarations in imported 
style sheets are considered to be before any declarations in the style 
sheet itself."

On 4/9/15 1:42 AM, Tom Eugelink wrote:
> Does the order in which things appear in a CSS have influence on the 
> behavior?
>
> Tom
>
>
> On 8-4-2015 23:22, David Grieve wrote:
>> The spec says that if there is an @import it has to appear first 
>> before any rule, except @charset, if present.
>>
>> On 4/8/15 5:12 PM, Tom Eugelink wrote:
>>> I'm currently porting and reworking some gauges from Enzo to 
>>> JFXtras. One of things that gets reworked involves that all gauges 
>>> will have custom colored segments. These segments can be preset 
>>> using colorschemes (e.g. green to red in 10 steps), so the CSS for 
>>> these colors are shared over all gauges. I tried using @import, but 
>>> since it is required to be the first lines in a CSS, I'm suspecting 
>>> that is the reason it is not working as expected.
>>>
>>> Is there any intention to allow these imports to occur half way in a 
>>> file? Placeholder-and-replace alike (#include), so to speak.
>>>
>>> Tom
>>
>


From cnewland at chrisnewland.com  Thu Apr  9 12:37:17 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Thu, 9 Apr 2015 13:37:17 +0100
Subject: Private APIs not usable in Java 9?
Message-ID: <7f7368d3aa457de29c9e3d26a78f6e81.squirrel@excalibur.xssl.net>

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

---
Hi Chris,

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

Cheers,
Martijn
---

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

An example from one of my own projects:

chris at 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-dev at openjdk.java.net is a
worthwhile effort to help them direct resources for bug fixing and new
public APIs.

Cheers,

Chris




From kevin.rushforth at oracle.com  Thu Apr  9 13:00:52 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 09 Apr 2015 06:00:52 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <CANEZrP19u2jJf=ZjuzVc7Aq1Pvr=3vRUry9OjQtrrL80rNkNcA@mail.gmail.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>
	<55261098.4030902@bestsolution.at>	<55263016.6090604@oracle.com>
	<CANEZrP19u2jJf=ZjuzVc7Aq1Pvr=3vRUry9OjQtrrL80rNkNcA@mail.gmail.com>
Message-ID: <55267804.5040008@oracle.com>


> I guess a good place to start would be to eliminate usage of private APIs
> from scene builder.

Agreed. I noted the needed to fix SceneBuilder in a comment in 
https://javafx-jira.kenai.com/browse/RT-40184 (wherein I said I would 
file a new JIRA, but hadn't done that yet). Jonathan has already 
generated the list of internal APIs from SceneBuilder, and can add it to 
the new JIRA I just filed:

https://javafx-jira.kenai.com/browse/RT-40486

-- Kevin



Mike Hearn wrote:
> I guess a good place to start would be to eliminate usage of private APIs
> from scene builder. I understand that it doesn't seem to be supported any
> more but it'd be extremely weird and embarrassing for Oracle if the UI
> builder tool broke on Java 9 given all the work that went into it.
> On 9 Apr 2015 9:54 am, "Jonathan Giles" <jonathan.giles at oracle.com> wrote:
>
>   
>> For what it is worth, investigations are underway in relation to UI
>> control skins and behaviors. It's too early for anything definitive to
>> announce, but it is not inconceivable that com.sun.javafx.scene.control.skin
>> may become javafx.scene.control.skin, more or less (with a lot of work
>> cleaning up, etc).
>>
>> In terms of behaviors, some investigations are already underway in
>> RT-21598, but these too are only early, and fall under the bigger project
>> of getting UI controls and CSS APIs into a jigsaw-friendly form for JDK 9
>> (which is a huge undertaking, and community support will be useful and
>> sought at the appropriate time).
>>
>> Thanks,
>>
>> -- Jonathan
>>
>> On 9/04/2015 5:39 p.m., Tom Schindl wrote:
>>
>>     
>>> Hi,
>>>
>>> in SWT on JavaFX (most likely NOT a common useage of JavaFX):
>>> -------------------------------------------------------------
>>> I had to reside to private-API when it comes to:
>>> * text calculations where there is no public API for things like
>>>    FontMetrics, TextLayout, ...
>>> * For some of the direct drawing code I had to use com.sun.javafx.geom.*
>>> * For some operations I had to access the com.sun.glass.ui.Robot &
>>>    com.sun.glass.ui.Application
>>> * I had to get access to the VirtualFlow
>>>
>>> To implement custom controls e.g. CodeEditor:
>>> ---------------------------------------------
>>> * com.sun.javafx.scene.control.skin.BehaviorSkinBase
>>> * com.sun.javafx.scene.control.behavior.KeyBinding
>>> * com.sun.javafx.css.converters.InsetsConverter
>>> * com.sun.javafx.css.converters.PaintConverter
>>> * com.sun.javafx.scene.text.HitInfo
>>>
>>> So to summerize the most lacking API is in the font/text rendering space
>>> and to get public access to VirtualFlow would be a nice to have!
>>>
>>> Tom
>>>
>>>
>>> On 08.04.15 18:44, Phil Race wrote:
>>>
>>>       
>>>>   it's not strictly JFX-only.
>>>>         
>>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>>> as being relatively new it does not have 20 years of accumulation
>>>> of people using internal APIs that the larger JDK does, often dating from
>>>> when there were no suitable public APIs. There still remains some
>>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>>> inaccessible in modular mode. But the FX list isn't really the place
>>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>>> is simply bound by the rules that are set there.
>>>>
>>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>>> transition.
>>>>
>>>> Also remember FX is open source. You can propose patches !
>>>> If there are specific APIs that are missing from FX that are suitable
>>>> to be *supported* public APIs then those could be considered here (this
>>>> list).
>>>>
>>>> -phil.
>>>>
>>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>>
>>>>         
>>>>> sed -i 's/private/public/g' ;)
>>>>>
>>>>> The whole notion of a strongly enforced private keyword is IMHO dumb
>>>>> when
>>>>> not using sandboxing. The number of gross hacks that occur in an
>>>>> attempt to
>>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>>> compiler has a special flag that disables visibility enforcement when
>>>>> compiling unit tests, and that's a good idea, but why not go all the way
>>>>> and just make accessing of private state a compiler warning a la
>>>>> deprecated?
>>>>>
>>>>> I also need to use private JFX APIs. I think any real JFX app does,
>>>>> way too
>>>>> much basic stuff relies on it. Heck, the number of popular Java
>>>>> libraries
>>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
>>>>> in
>>>>> this regard then I will just write a simple tool that flips
>>>>> private->public
>>>>> either at the source level or via bytecode editing, and see what
>>>>> happens :-)
>>>>>
>>>>>
>>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Kr?ger <krueger at lesspain.de>
>>>>> wrote:
>>>>>
>>>>>  Hi,
>>>>>           
>>>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>>>> context it's not strictly JFX-only.
>>>>>>
>>>>>> Someone from our team recently had a chat with a high-ranking regional
>>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>>>> product,
>>>>>> feeling it's in principle the right technology but still having
>>>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>>>> relay our concrete questions to the right people, which he did.
>>>>>>
>>>>>> The answer we got contained one thing that really was a bit of a
>>>>>> shock and
>>>>>> I would like someone to either confirm this or clear up a
>>>>>> misunderstanding.
>>>>>>
>>>>>> The statement was that private APIs will not be available in JDK 9
>>>>>> due to
>>>>>> modularity restrictions. If that is the case and we no longer have the
>>>>>> ability to build temporary workarounds using private APIs (which in our
>>>>>> case is controllable as we ship the JRE with our product), I would
>>>>>> probably
>>>>>> have to stop any development going into the direction of JFX as we will
>>>>>> probably have to use 9 at some point because many things now
>>>>>> scheduled for
>>>>>> 9 will not get fixed in 8 and we will most likely still need
>>>>>> workarounds
>>>>>> using private API, at least that's what my current experience with JFX
>>>>>> tells me.
>>>>>>
>>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>>> general case where one does not ship the JRE) or a non-engineering
>>>>>> source
>>>>>> that simply made mistake.
>>>>>>
>>>>>> Best regards and thanks in advance,
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>>             

From tbee at tbee.org  Thu Apr  9 15:11:37 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Thu, 09 Apr 2015 17:11:37 +0200
Subject: @import in CSS
In-Reply-To: <552663CF.40805@oracle.com>
References: <552599C4.8090608@tbee.org>
	<55259C07.2020904@oracle.com>	<55261157.9010402@tbee.org>
	<552663CF.40805@oracle.com>
Message-ID: <552696A9.5010306@tbee.org>

Hm. That would mean this should work, but it does not. So instead of moving the lines 216 and up to a separate file, I moved them to the front, but the colorschemes are not working then. The lines must be after the first (.SimpleMetroArcGauge) block. I don't understand why this matters, if it is declaration based.

https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css


On 9-4-2015 13:34, David Grieve wrote:
> Yes. The details are in http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is the excerpt that matters: " if two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations in the style sheet itself."
>
> On 4/9/15 1:42 AM, Tom Eugelink wrote:
>> Does the order in which things appear in a CSS have influence on the behavior?
>>
>> Tom
>>
>>
>> On 8-4-2015 23:22, David Grieve wrote:
>>> The spec says that if there is an @import it has to appear first before any rule, except @charset, if present.
>>>
>>> On 4/8/15 5:12 PM, Tom Eugelink wrote:
>>>> I'm currently porting and reworking some gauges from Enzo to JFXtras. One of things that gets reworked involves that all gauges will have custom colored segments. These segments can be preset using colorschemes (e.g. green to red in 10 steps), so the CSS for these colors are shared over all gauges. I tried using @import, but since it is required to be the first lines in a CSS, I'm suspecting that is the reason it is not working as expected.
>>>>
>>>> Is there any intention to allow these imports to occur half way in a file? Placeholder-and-replace alike (#include), so to speak.
>>>>
>>>> Tom
>>>
>>
>


From anton.tarasov at oracle.com  Thu Apr  9 15:45:57 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Thu, 09 Apr 2015 18:45:57 +0300
Subject: [9] post-commit notification: RT-40489 NPE in
	javafx.embed.swing.JFXPanel$HostContainer
Message-ID: <55269EB5.60308@oracle.com>

JIRA: https://javafx-jira.kenai.com/browse/RT-40489
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ad5669aafe66

Regards,
Anton.

From david.grieve at oracle.com  Thu Apr  9 15:59:16 2015
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 09 Apr 2015 11:59:16 -0400
Subject: @import in CSS
In-Reply-To: <552696A9.5010306@tbee.org>
References: <552599C4.8090608@tbee.org>	<55259C07.2020904@oracle.com>	<55261157.9010402@tbee.org>	<552663CF.40805@oracle.com>
	<552696A9.5010306@tbee.org>
Message-ID: <5526A1D4.6030702@oracle.com>

Take -fxx-needle-color (from SimpleMetroArcGauge.css) as an example. Its 
declaration appears in the .SimpleMetroArcGauge rule and is then used in 
the -fx-fill declaration of the .needle rule. The CSS parser is pretty 
dumb. It collects up the property names as it parses and if any of those 
property names appears a a property value, it marks the property value 
as needing to be looked up. Then, at run time, if a property has a value 
that needs to be looked up, the CSS engine goes from the node up to the 
root looking for a declaration that resolves the property to a real 
value. Anyway, the point is, you can't have forward references for these 
lookup values.

Note also that the .needle node has to be a .SimpleMetroArcGauge or a 
child of a .SimpleMetroArcGauge for the lookup to work. In modena.css, 
for example, all of the lookup properties are declared in the .root rule 
so this isn't an issue. You could do the same or be more explicit in 
your rules by saying, e.g.,

.needle { -fx-fill: orange; }
.SimpleMetroArcGauge .needle { -fx-fill: -fxx-needle-color; }

In this way, a needle that is a child of .SimpleMetroArcGauge will pick 
up -fxx-needle-color, but a .needle that is not will be orange.


On 4/9/15 11:11 AM, Tom Eugelink wrote:
> Hm. That would mean this should work, but it does not. So instead of 
> moving the lines 216 and up to a separate file, I moved them to the 
> front, but the colorschemes are not working then. The lines must be 
> after the first (.SimpleMetroArcGauge) block. I don't understand why 
> this matters, if it is declaration based.
>
> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 
>
>
>
> On 9-4-2015 13:34, David Grieve wrote:
>> Yes. The details are in 
>> http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is 
>> the excerpt that matters: " if two declarations have the same weight, 
>> origin and specificity, the latter specified wins. Declarations in 
>> imported style sheets are considered to be before any declarations in 
>> the style sheet itself."
>>
>> On 4/9/15 1:42 AM, Tom Eugelink wrote:
>>> Does the order in which things appear in a CSS have influence on the 
>>> behavior?
>>>
>>> Tom
>>>
>>>
>>> On 8-4-2015 23:22, David Grieve wrote:
>>>> The spec says that if there is an @import it has to appear first 
>>>> before any rule, except @charset, if present.
>>>>
>>>> On 4/8/15 5:12 PM, Tom Eugelink wrote:
>>>>> I'm currently porting and reworking some gauges from Enzo to 
>>>>> JFXtras. One of things that gets reworked involves that all gauges 
>>>>> will have custom colored segments. These segments can be preset 
>>>>> using colorschemes (e.g. green to red in 10 steps), so the CSS for 
>>>>> these colors are shared over all gauges. I tried using @import, 
>>>>> but since it is required to be the first lines in a CSS, I'm 
>>>>> suspecting that is the reason it is not working as expected.
>>>>>
>>>>> Is there any intention to allow these imports to occur half way in 
>>>>> a file? Placeholder-and-replace alike (#include), so to speak.
>>>>>
>>>>> Tom
>>>>
>>>
>>
>


From mikegps1 at gmail.com  Thu Apr  9 16:11:37 2015
From: mikegps1 at gmail.com (Mike)
Date: Thu, 9 Apr 2015 09:11:37 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
Message-ID: <07E8CC8A-B68C-421B-905D-8D63C8357B0B@gmail.com>

This is important 
Thanks guys 

Sent from my iPhone

> On Apr 8, 2015, at 9:25 AM, Chris Newland <cnewland at chrisnewland.com> wrote:
> 
> Hi Jim,
> 
> I'll post the verbose prism output from my iMac when I get home.
> 
> Just tried this on my Linux workstation and the performance gap is the
> same between es2 and sw so I don't think it's an OSX issue.
> 
> uname -a
> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
> 
> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 20
> fps: 31
> fps: 32
> fps: 33
> fps: 35
> fps: 34
> fps: 33
> 
> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 54
> fps: 56
> fps: 60
> fps: 59
> fps: 60
> fps: 61
> fps: 61
> fps: 60
> 
> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
> graphics card running driver 304.125
> 
> Regards,
> 
> Chris
> 
> 
>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>> install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
>> so my theory that something changed in the OGL implementation for 10.10
>> doesn't hold water.
>> 
>> But, I then tried it using the integrated graphics.  I get really poor
>> performance using the integrated Intel 4000 graphics, but I get great
>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>> graphics wouldn't be as powerful as the discrete graphics, but we
>> shouldn't be taxing it that much to make that big of a difference.
>> 
>> Just to be sure - is that iMac a dual graphics system, or is it
>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>> with -Dprism.verbose=true...
>> 
>> ...jim
>> 
>> 
>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>> 
>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>> running a newer version of MacOS?
>>> 
>>> ...jim
>>> 
>>> 
>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>> 
>>>> Hi Herv?,
>>>> 
>>>> 
>>>> That's a valid question :)
>>>> 
>>>> 
>>>> Probably because
>>>> 
>>>> 
>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>> systems
>>>> 
>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>> to go for that due to the very large number of nodes.
>>>> 
>>>> Numbers for my Sierpinski filled triangle example:
>>>> 
>>>> 
>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>> 1024 MB
>>>> 
>>>> 
>>>> java -Dprism.order=es2 -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 23
>>>> fps: 18
>>>> fps: 25
>>>> fps: 18
>>>> fps: 23
>>>> fps: 23
>>>> fps: 19
>>>> fps: 25
>>>> 
>>>> 
>>>> java -Dprism.order=sw -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 54
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> 
>>>> 
>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>> 1.8.0_40
>>>> 
>>>> 
>>>> I would say there is a performance problem here? (or at least a need
>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>> 
>>>> Best regards,
>>>> 
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>> 
>>>>> Why don't you use Nodes rather than Canvas ?
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>> <cnewland at chrisnewland.com>
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Hi Jim,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks, that makes things much clearer.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I was surprised how much was going on under the hood of
>>>>>> GraphicsContext
>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>> acceleration where available and immediate-mode-like simple
>>>>>> rasterizing where not.
>>>>>> 
>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>> so I expect suffers from the problem you've described.
>>>>>> 
>>>>>> SSCCE:
>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>> com/ch
>>>>>> 
>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>> 
>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>> JavaFX or
>>>>>> would I be better off with Graphics2D?
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>> with a GPU
>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>> with an appropriate shader which is very fast.
>>>>>>> 
>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>> like:
>>>>>>> 
>>>>>>> 
>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>> drawLine() - dealing with only rendering common points of
>>>>>>> intersection once
>>>>>>> 
>>>>>>> To handle all of that complexity we have to involve a
>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>> currently for all pipelines.
>>>>>>> 
>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>> CPU path
>>>>>>> rasterization.
>>>>>>> 
>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>> dominates its performance.
>>>>>>> 
>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>> 
>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>> case. Does
>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>> SW
>>>>>>> pipeline for the polygon case?
>>>>>>> 
>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>> calls faster than drawPolygon as well...
>>>>>>> 
>>>>>>> ...jim
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Robert,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>> I'd
>>>>>>>> better add my findings.
>>>>>>>> 
>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>> strokeLine commands as expected:
>>>>>>>> 
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>> Result:
>>>>>>>> 44fps
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>> Result:
>>>>>>>> 60fps
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>> examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>> 
>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>> JavaFX
>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>> do think there's a bug here.
>>>>>>>> 
>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>> slow" ;)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 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(Op
>>>>>>>>> en%2C% 20%2
>>>>>>>>> 2In%
>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>> 20%20A
>>>>>>>>> ND%2
>>>>>>>>> 0la
>>>>>>>>> bels%20in%20(performance)
>>>>>>>>> 
>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>> least OSX and Windows and
>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>> 
>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>> across diverse platforms"
>>>>>>>>> 
>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>> (8u40)
>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>> performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>> 
>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>> performance that can be tracked?
>>>>>>>>> 
>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>> the best.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Possibly related:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>> count) command.
>>>>>>>>>> 
>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>> 
>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Build with ant
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Run with:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> # use strokeLine
>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> # use strokePolygon
>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>> 20GB RAM
>>>>>>>>>> /
>>>>>>>>>> Radeon
>>>>>>>>>> 6970M 1024MB
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Looking at the code paths in
>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>> than using the convenience method.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Chris
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>> It is
>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>> predetermined shader, but it shouldn't be that
>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>> changes...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>> AnimationTimer
>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Robert Kr??ger
>>>>>>>>> Managing Partner
>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> www.lesspain-software.com
> 
> 

From tbee at tbee.org  Thu Apr  9 17:50:25 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Thu, 09 Apr 2015 19:50:25 +0200
Subject: @import in CSS
In-Reply-To: <5526A1D4.6030702@oracle.com>
References: <552599C4.8090608@tbee.org>	<55259C07.2020904@oracle.com>	<55261157.9010402@tbee.org>	<552663CF.40805@oracle.com>	<552696A9.5010306@tbee.org>
	<5526A1D4.6030702@oracle.com>
Message-ID: <5526BBE1.7040607@tbee.org>

I suspected as much, and that really is a shame because it cripples the declaration based behavior. The parser could of course declare any property it does not know at the time of parsing as needed to be looked up. Ultimately I cannot move the colorschemes into a separate file, so they are reusable by all gauges,, because the import must preceed any declarations.

All classes in the CSS are below .SimpleMetroArcGauge, I will prefix them. What I really want to do is reuse the -fxx-needle-color for each gauge, that is: multiple instances of the same control, but also different gauges, so I can have a universal set of colorscheme's applicable to every gauge.

Maybe I should have a look at placeholders and let Gradle / Maven resolve them.


On 9-4-2015 17:59, David Grieve wrote:
> Take -fxx-needle-color (from SimpleMetroArcGauge.css) as an example. Its declaration appears in the .SimpleMetroArcGauge rule and is then used in the -fx-fill declaration of the .needle rule. The CSS parser is pretty dumb. It collects up the property names as it parses and if any of those property names appears a a property value, it marks the property value as needing to be looked up. Then, at run time, if a property has a value that needs to be looked up, the CSS engine goes from the node up to the root looking for a declaration that resolves the property to a real value. Anyway, the point is, you can't have forward references for these lookup values.
>
> Note also that the .needle node has to be a .SimpleMetroArcGauge or a child of a .SimpleMetroArcGauge for the lookup to work. In modena.css, for example, all of the lookup properties are declared in the .root rule so this isn't an issue. You could do the same or be more explicit in your rules by saying, e.g.,
>
> .needle { -fx-fill: orange; }
> .SimpleMetroArcGauge .needle { -fx-fill: -fxx-needle-color; }
>
> In this way, a needle that is a child of .SimpleMetroArcGauge will pick up -fxx-needle-color, but a .needle that is not will be orange.
>
>
> On 4/9/15 11:11 AM, Tom Eugelink wrote:
>> Hm. That would mean this should work, but it does not. So instead of moving the lines 216 and up to a separate file, I moved them to the front, but the colorschemes are not working then. The lines must be after the first (.SimpleMetroArcGauge) block. I don't understand why this matters, if it is declaration based.
>>
>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css
>>
>>
>> On 9-4-2015 13:34, David Grieve wrote:
>>> Yes. The details are in http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is the excerpt that matters: " if two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations in the style sheet itself."
>>>
>>> On 4/9/15 1:42 AM, Tom Eugelink wrote:
>>>> Does the order in which things appear in a CSS have influence on the behavior?
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 8-4-2015 23:22, David Grieve wrote:
>>>>> The spec says that if there is an @import it has to appear first before any rule, except @charset, if present.
>>>>>
>>>>> On 4/8/15 5:12 PM, Tom Eugelink wrote:
>>>>>> I'm currently porting and reworking some gauges from Enzo to JFXtras. One of things that gets reworked involves that all gauges will have custom colored segments. These segments can be preset using colorschemes (e.g. green to red in 10 steps), so the CSS for these colors are shared over all gauges. I tried using @import, but since it is required to be the first lines in a CSS, I'm suspecting that is the reason it is not working as expected.
>>>>>>
>>>>>> Is there any intention to allow these imports to occur half way in a file? Placeholder-and-replace alike (#include), so to speak.
>>>>>>
>>>>>> Tom
>>>>>
>>>>
>>>
>>
>


From kevin.rushforth at oracle.com  Thu Apr  9 18:02:57 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 09 Apr 2015 11:02:57 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <7f7368d3aa457de29c9e3d26a78f6e81.squirrel@excalibur.xssl.net>
References: <7f7368d3aa457de29c9e3d26a78f6e81.squirrel@excalibur.xssl.net>
Message-ID: <5526BED1.1040608@oracle.com>

I'll second the recommendation to run jdeps on your apps. I note that it 
doesn't currently flag internal FX packages as internal. I filed the 
following RFE to address this:

https://bugs.openjdk.java.net/browse/JDK-8077349

-- Kevin


Chris Newland wrote:
> I just asked about this on the adoption-discuss at openjdk.java.net list and
> the answer from Martijn Verburg is:
>
> ---
> Hi Chris,
>
> I think the strong advice for those using private APIs is to run the jdeps
> tool to see where they are using APIs that will go away / be moved. I'd
> then get them to post that list to jigsaw-dev, I guess the root cause of
> some of these issues should also be logged in JBS and fixed :-).
>
> Cheers,
> Martijn
> ---
>
> If you run $JAVA_HOME/bin/jdeps -jdkinternals <class dir or jar> then it
> will show all uses of JDK private APIs that will go away in JDK9.
>
> An example from one of my own projects:
>
> chris at 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-dev at openjdk.java.net is a
> worthwhile effort to help them direct resources for bug fixing and new
> public APIs.
>
> Cheers,
>
> Chris
>
>
>
>   

From david.dehaven at oracle.com  Thu Apr  9 18:17:38 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 9 Apr 2015 11:17:38 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <5526BED1.1040608@oracle.com>
References: <7f7368d3aa457de29c9e3d26a78f6e81.squirrel@excalibur.xssl.net>
	<5526BED1.1040608@oracle.com>
Message-ID: <BE8E5EF8-B43B-49CF-ACEF-331E79562E18@oracle.com>

You can see any com.sun.* usage by running "jdeps -v some.jar". You'll have to sort it all out manually, but it's all there.

-DrD-

> I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this:
> 
> https://bugs.openjdk.java.net/browse/JDK-8077349
> 
> -- Kevin
> 
> 
> Chris Newland wrote:
>> I just asked about this on the adoption-discuss at openjdk.java.net list and
>> the answer from Martijn Verburg is:
>> 
>> ---
>> Hi Chris,
>> 
>> I think the strong advice for those using private APIs is to run the jdeps
>> tool to see where they are using APIs that will go away / be moved. I'd
>> then get them to post that list to jigsaw-dev, I guess the root cause of
>> some of these issues should also be logged in JBS and fixed :-).
>> 
>> Cheers,
>> Martijn
>> ---
>> 
>> If you run $JAVA_HOME/bin/jdeps -jdkinternals <class dir or jar> then it
>> will show all uses of JDK private APIs that will go away in JDK9.
>> 
>> An example from one of my own projects:
>> 
>> chris at 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-dev at openjdk.java.net is a
>> worthwhile effort to help them direct resources for bug fixing and new
>> public APIs.
>> 
>> Cheers,
>> 
>> Chris
>> 
>> 
>> 
>>  


From kevin.rushforth at oracle.com  Thu Apr  9 18:56:54 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 09 Apr 2015 11:56:54 -0700
Subject: Private APIs not usable in Java 9?
In-Reply-To: <BE8E5EF8-B43B-49CF-ACEF-331E79562E18@oracle.com>
References: <7f7368d3aa457de29c9e3d26a78f6e81.squirrel@excalibur.xssl.net>
	<5526BED1.1040608@oracle.com>
	<BE8E5EF8-B43B-49CF-ACEF-331E79562E18@oracle.com>
Message-ID: <5526CB76.8020902@oracle.com>

Right. The specific list of JavaFX internal packages is listed in the 
JIRA I filed, but if you just grep for 'com.sun' that will hit all of them.

-- Kevin


David DeHaven wrote:
> You can see any com.sun.* usage by running "jdeps -v some.jar". You'll have to sort it all out manually, but it's all there.
>
> -DrD-
>
>   
>> I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8077349
>>
>> -- Kevin
>>
>>
>> Chris Newland wrote:
>>     
>>> I just asked about this on the adoption-discuss at openjdk.java.net list and
>>> the answer from Martijn Verburg is:
>>>
>>> ---
>>> Hi Chris,
>>>
>>> I think the strong advice for those using private APIs is to run the jdeps
>>> tool to see where they are using APIs that will go away / be moved. I'd
>>> then get them to post that list to jigsaw-dev, I guess the root cause of
>>> some of these issues should also be logged in JBS and fixed :-).
>>>
>>> Cheers,
>>> Martijn
>>> ---
>>>
>>> If you run $JAVA_HOME/bin/jdeps -jdkinternals <class dir or jar> then it
>>> will show all uses of JDK private APIs that will go away in JDK9.
>>>
>>> An example from one of my own projects:
>>>
>>> chris at 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-dev at openjdk.java.net is a
>>> worthwhile effort to help them direct resources for bug fixing and new
>>> public APIs.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>
>>>
>>>  
>>>       
>
>   

From snfuchs at gmx.de  Thu Apr  9 19:45:40 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Thu, 09 Apr 2015 21:45:40 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <55259A02.2040902@gmx.de>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>
	<552579C2.5020000@gmx.de>	<55257E5E.9010304@oracle.com>
	<55257FAD.9040308@gmx.de>	<CAEnqZEVFM6_MJSZQ5m-ek=zJ_05mThhfz9Hzzj6nOL25+-zcTA@mail.gmail.com>
	<74911AD1-330F-4447-8628-59BF16FBCA8E@oracle.com>
	<55259A02.2040902@gmx.de>
Message-ID: <5526D6E4.9020405@gmx.de>

Hi,

as promised here is the list of current private api usages of our application.
Any advice how to achieve the same with public apis is always welcome.


* We use com.sun.webkit.WebPage and com.sun.javafx.webkit.Accessor to implement our own frontend for the html editor.
   It seems to be unmaintained by oracle. Has anyone used an texteditor, where it is not possible to do a line break
   (https://javafx-jira.kenai.com/browse/RT-38412)? Bug was filed August 2014 and was deferred from 8u40 to 9.
   The bug can only be tracked down by oracle, because the bug is probably in the plugin code, which is still closed source.
   Well we have a semi working workaround involving private apis...
   Whatever we currently implement a new text editor based on TextFlow, because the html editor is simply too buggy.
   So for us this will no longer an issue with Java 9.

* com.sun.javafx.scene.control.skin.ComboBoxListViewSkin is used to scroll to entry matching typed key in a ComboBoxListView
   There is a feature request from 2011 for this: https://javafx-jira.kenai.com/browse/RT-18064.
   Perhaps its enough to expose scrollTo. That is https://javafx-jira.kenai.com/browse/RT-34661.

    fontFamilyComboBox.setOnKeyPressed(new EventHandler<KeyEvent>() {
             	
		@Override
                 	public void handle(KeyEvent event) {
             		
             			if (fontFamilyComboBox.isShowing()) {

     	        			@SuppressWarnings("rawtypes")
     	        			ListView cbListView = ((ComboBoxListViewSkin) fontFamilyComboBox.getSkin()).getListView();
     	        		
					String typed = event.getCode().toString().toLowerCase();
     	            			ObservableList<String> fontList = fontFamilyComboBox.getItems();
     	            			for (int i = 0; i < fontList.size(); i++) {
     	            				String font = fontList.get(i).toLowerCase();
     	            				if (font.startsWith(typed)) {
     	            					fontFamilyComboBox.getSelectionModel().clearAndSelect(i);
     	            					cbListView.scrollTo(i);
     	            					break;
     	            				}
     	            			}		
             			}
		}
	});

* We maximize our application window to full screen on startup with this code
This is a workaround for https://javafx-jira.kenai.com/browse/RT-32422

import com.sun.glass.ui.Window;
import com.sun.javafx.application.PlatformImpl;

             if (!isEmbedded && Window.getFocusedWindow() != null) {
                 Logger.getLogger(getClass()).debug(Settings.getInstance().getBoolProperty("mainStageMaximized", true));
                 try {
                     Window.getFocusedWindow().maximize(Settings.getInstance().getBoolProperty("mainStageMaximized", true));
                 } catch (Exception e) {
                     // java.lang.IllegalStateException: The window has already been closed on linux
                 }
                 Logger.getLogger(getClass()).info("maximized focused window " + Window.getFocusedWindow().getTitle());
                 
          }

* ComboBoxes, we have the requirement to automatically open comboboxes on mouseover. The combobox should not be closed on mouseclick:

  Expose the value of isHideOnClickEnabled in our ExtendedComboBox control.

	@Override
	protected Skin<?> createDefaultSkin() {
		Skin<?> s = new ComboBoxListViewSkin<T>(this){
         	
			@Override
			protected boolean isHideOnClickEnabled() {
				return getIsHideOnClickEnabled();
			}
			
			@Override
			protected PopupControl getPopup() {
				PopupControl p = super.getPopup();
				p.autoHideProperty().bind(autoHideProperty);
				return p;
			}
         		};
   		return s;
     	}


* com.sun.glass.ui.Robot is used to work around a bug, that the Browser window does not get focus after the SWT-Filedialog is closed on Mac
-> We would not have to use the SWT-Filedialog at all and could use the JavaFX-Filedialog, ifhttps://javafx-jira.kenai.com/browse/RT-38809  was fixed.

Browser Mode: activate browser after swt-filedialog has been closed
             if(EditorFX.getInstance().getHostServices().getWebContext()!=null) {
                 LOG.debug("disposeAll -> create Robot");
                 Robot robot = com.sun.glass.ui.Application.GetApplication().createRobot();
                 if(robot!=null) {
                     robot.mousePress(1);
                     robot.mouseRelease(1);
                     robot.destroy();
                     LOG.debug("disposeAll -> Robot destroyed");
                 }
             }

* com.sun.glass.ui.Robot is also used to get screen coordinates for checks, if the mouse is over a node or not.
  We found that mouseEntered and mouseExited events do not work reliable. E.g.: mouseExited Events not triggered, mouseEntered are triggered before mouseExited on previous node)

* Gather various information about the used hardware in case of an unhandled exception.
   In case of an unhandled exception we gather various information about the affected computer and ask the user to upload it to us for further analysis.
  Our dialog is similar to what Firefox does:https://support.mozilla.org/en-US/kb/mozillacrashreporter
  These are some of our hacks to get information about the current hardware used:

	public static long getTotalPhysicalMemorySize() {
		com.sun.management.OperatingSystemMXBean os = (com.sun.management.OperatingSystemMXBean)
			     java.lang.management.ManagementFactory.getOperatingSystemMXBean();
		return os.getTotalPhysicalMemorySize();
	}
	
	public static long getFreePhysicalMemorySize() {
		com.sun.management.OperatingSystemMXBean os = (com.sun.management.OperatingSystemMXBean)
			     java.lang.management.ManagementFactory.getOperatingSystemMXBean();
		return os.getFreePhysicalMemorySize();



getWindowsGraphicCardInfo retrieves the same information, which would have been logged by prism.verbose=true

public class WindowsHardwareInfo {

	public static String getWindowsGraphicCardInfo() {
		
		String info = "";
		
		try {
			// ResourceFactory resourceFactory = D3DPipeline.getDefaultResourceFactory()
			Class<?> d3DPipelineClass = (Class<?>) Class.forName("com.sun.prism.d3d.D3DPipeline");
			Method getDefaultResourceFactoryMethod = d3DPipelineClass.getMethod("getDefaultResourceFactory");
			ResourceFactory resourceFactory = (ResourceFactory) getDefaultResourceFactoryMethod.invoke(null);
			
			info += "Maximum texture size: " + resourceFactory.getMaximumTextureSize() + "\n" ;
			
			// int adapterCount = D3DPipeline.nGetAdapterCount()
			Method nGetAdapterCountMethod =  d3DPipelineClass.getDeclaredMethod("nGetAdapterCount");
			nGetAdapterCountMethod.setAccessible(true);
			int adapterCount = (Integer) nGetAdapterCountMethod.invoke(null);
			
			Class<?> d3DDriverInformationClass = (Class<?>) Class.forName("com.sun.prism.d3d.D3DDriverInformation");
			Method nGetDriverInformationMethod = d3DPipelineClass.getDeclaredMethod("nGetDriverInformation", int.class, d3DDriverInformationClass );
			nGetDriverInformationMethod.setAccessible(true);

			Constructor<?> constructor = d3DDriverInformationClass.getDeclaredConstructor();
			constructor.setAccessible(true);

			for (int adapter = 0, n = adapterCount; adapter != n; ++adapter) {
				//D3DPipeline.nGetDriverInformation(adapter, new D3DDriverInformation());
				Object di = nGetDriverInformationMethod.invoke(null, adapter, constructor.newInstance());
			
			    if (di != null) {
			    	info += "Graphics adapter #" + adapter + "\n";
			    	info += "OS Information:\n";
			    	info += "\t" + callGetter(di, d3DDriverInformationClass, "getOsVersion") + " build " + getField(di, d3DDriverInformationClass, "osBuildNumber") + "\n";
			    	info += "D3D Driver Information:\n";
			    	info += "\t" + getField(di, d3DDriverInformationClass, "deviceDescription")  + "\n";
			    	info += "\t" + getField(di, d3DDriverInformationClass, "deviceName") + "\n";
			    	info += "\tDriver " + getField(di, d3DDriverInformationClass, "driverName") + ", version " + callGetter(di, d3DDriverInformationClass, "getDriverVersion") + "\n";
			    	info += "\tPixel Shader version " + getField(di, d3DDriverInformationClass, "psVersionMajor") + "." + getField(di, d3DDriverInformationClass, "psVersionMinor") + "\n";
			    	info += "\tDevice : " + callGetter(di, d3DDriverInformationClass, "getDeviceID") + "\n";
//		            System.out.println("\tMax Multisamples supported: " + di.maxSamples);
			        Object warning = getField(di, d3DDriverInformationClass, "warningMessage");
			        if (warning != null) {
			        	info += "\t *** " + warning + "\n";
			        }
			    }
			}
		} catch (Exception e) {
			info += "Unable to retrieve hardware info: " + e.getMessage();
		}
			
		return info;
	}
	
	private static Object callGetter(Object object, Class<?> objectClass, String methodName) throws NoSuchMethodException, SecurityException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
		Method method = objectClass.getDeclaredMethod(methodName);
		method.setAccessible(true);
		return method.invoke(object);
	}
	
	private static Object getField(Object object, Class<?> objectClass, String fieldName) throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException {
		Field field = objectClass.getDeclaredField(fieldName);
		field.setAccessible(true);
		return field.get(object);
	}


For OutOfMemory exceptions, we create a heapdump file like this:

     public static void dumpHeap(String fileName, boolean live) throws Exception {
         // initialize hotspot diagnostic MBean
     	Object hotspotMBean = getHotspotMBean();
         Class<?> clazz = Class.forName("com.sun.management.HotSpotDiagnosticMXBean");
         Method m = clazz.getMethod("dumpHeap", String.class, boolean.class);
         m.invoke( hotspotMBean , fileName, live);
     }

     // get the hotspot diagnostic MBean from the
     // platform MBean server
     private static Object getHotspotMBean() throws ClassNotFoundException, IOException {
         Class<?> clazz = Class.forName("com.sun.management.HotSpotDiagnosticMXBean");
         MBeanServer server = ManagementFactory.getPlatformMBeanServer();
         return ManagementFactory.newPlatformMXBeanProxy(server, HOTSPOT_BEAN_NAME, clazz);
     }


These are the current usages of private apis in our application.
However we include various other libraries, which I have not checked yet. Some of them are no longer maintained.

So obviously for most of the problems there are open jiras, many of them years old.


- Stefan

> I' ll try to compile a list of the private apis we currently use in 
> our application and why.
>
> Looking forward to using only public apis in java 9 then :-)
>
> - Stefan
>
>>> On Apr 8, 2015, at 1:52 PM, Robert Kr?ger <krueger at lesspain.de> wrote:
>>>   our only workaround is to use private API
>> For the benefit of the devs on the list, could you please point out 
>> what private APIs you currently need to use?  That way we can make 
>> sure proper JIRAs are filed and we can connect those to actual 
>> real-world problems.
>


From jeffhain at rocketmail.com  Thu Apr  9 20:28:27 2015
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Thu, 9 Apr 2015 20:28:27 +0000 (UTC)
Subject: Private APIs not usable in Java 9? - behind the scene
In-Reply-To: <55261098.4030902@bestsolution.at>
References: <55261098.4030902@bestsolution.at>
Message-ID: <79239062.4099149.1428611307349.JavaMail.yahoo@mail.yahoo.com>


Tom Schindl wrote:>So to summerize the most lacking API is in the font/text rendering space
What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features :- Something like WritableImage.getGraphicsContext() (as we have Image.getGraphics()).- Something like GraphicsContext.setXORMode(Color) (as we have Graphics.setXORMode(Color))? (for example for drawing a kind of cursor in a Canvas).- Easier reading of Canvas pixels.? The only way I found to just read a pixel in a Canvas, is to call Canvas.snapshot(...)? (which needs to be called in FX application thread) with parameters corresponding? to that pixel, and then do getPixelReader().getArgb(0, 0) on the returned WritableImage.
For simplicity of my code (minimalistic dependencies and cognitive load, easy-or-no bug),its adaptability (I might want to make it easy to do things JDK UI libraries have not been designed for),and its portability (I want it to run on top of AWT, JavaFX, OpenGL, or whatever widely supportedframework of the day), I don't want to commit myself to most of the JavaFX API, like the Scene Graphand Nodes, and just want to use Canvas, mouse/key events, and Stages and their events as windows,in some adaptation layer.
There might be some minimalistic windowing frameworks etc. out there in C,but I like the "write once run anywhere" of Java so I try to stick to it for now.

What I'm looking for surely exists behind the scene (accidental pun),but dispatched over internal layers (Glass, Quantum, etc.),
and not regrouped into a consistent public API.

-Jeff

From jeffhain at rocketmail.com  Thu Apr  9 20:57:56 2015
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Thu, 9 Apr 2015 20:57:56 +0000 (UTC)
Subject: Private APIs not usable in Java 9? - behind the scene
In-Reply-To: <79239062.4099149.1428611307349.JavaMail.yahoo@mail.yahoo.com>
References: <79239062.4099149.1428611307349.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <373154538.4074129.1428613076668.JavaMail.yahoo@mail.yahoo.com>

[Re-sending with more line breaks (hopefully - looked fine when sent?but most were gone when I received it)]



Tom Schindl wrote:>So to summerize the most lacking API is in the font/text rendering space

What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features :
- Something like WritableImage.getGraphicsContext() (as we have Image.getGraphics()).
- Something like GraphicsContext.setXORMode(Color) (as we have Graphics.setXORMode(Color))? (for example for drawing a kind of cursor in a Canvas).
- Easier reading of Canvas pixels.? The only way I found to just read a pixel in a Canvas, is to call Canvas.snapshot(...)? (which needs to be called in FX application thread) with parameters corresponding? to that pixel,? and then do getPixelReader().getArgb(0, 0) on the returned WritableImage.

For simplicity of my code (minimalistic dependencies and cognitive load, easy-or-no bug),its adaptability (I might want to make it easy to do things JDK UI libraries have not been designed for),and its portability (I want it to run on top of AWT, JavaFX, OpenGL, or whatever widely supportedframework of the day), I don't want to commit myself to most of the JavaFX API, like the Scene Graphand Nodes, and just want to use Canvas, mouse/key events, and Stages and their events as windows,in some adaptation layer.

There might be some minimalistic windowing frameworks etc. out there in C,but I like the "write once run anywhere" of Java so I try to stick to it for now.

What I'm looking for surely exists behind the scene (accidental pun),but dispatched over internal layers (Glass, Quantum, etc.),and not regrouped into a consistent public API.


-Jeff

  

From mik3hall at gmail.com  Thu Apr  9 21:35:48 2015
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 9 Apr 2015 16:35:48 -0500
Subject: javapackager
Message-ID: <D9655FE8-4553-4C78-8C0D-B8BB32C9E3CE@gmail.com>

It was indicated that this might be the list for questions on javapackager.

This could very well just be that some OS X customization hasn?t been done yet for the java 9 early access but a javapackager application gets the following error if I replace the default Java 8 jdk with the java 9 and change JVMRuntime in the Info.plist file to reflect that. 
It default sets Java 8 as the embedded runtime, I?m not familiar enough with javapackager to know how to override that, so I change it manually. 
Embedded Java 9 got?,

4/2/15 7:03:23.334 PM TestApp[4354]: Could not get function pointer for JLI_Launch.: (
	0   CoreFoundation                      0x00007fff9466025c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff95bf8e75 objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff9466010c +[NSException raise:format:] + 204
	3   TestApp                             0x000000010e327de1 launch + 593
	4   TestApp                             0x000000010e327366 main + 70
	5   TestApp                             0x000000010e327314 start + 52
)

This is a fairly simple test application, it just puts up an empty JFrame, it did work with the Java 8 runtime embedded.

Michael Hall





From snfuchs at gmx.de  Thu Apr  9 22:13:01 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Fri, 10 Apr 2015 00:13:01 +0200
Subject: Private APIs not usable in Java 9?
In-Reply-To: <552637F5.5090005@oracle.com>
References: <CAEnqZEXUgsDEfJ9xGjQezvoJQzWcttvc-W9MEGg0L3eVbH-9+Q@mail.gmail.com>	<CANEZrP0Wbd7CtsdFiQMAmkmfs58iyK_bYEnmOE-LCEo9Xz=SrQ@mail.gmail.com>	<55255AE1.2070302@oracle.com>	<552579C2.5020000@gmx.de>	<55257E5E.9010304@oracle.com>	<55257FAD.9040308@gmx.de>	<55259798.80803@gmx.de>
	<552637F5.5090005@oracle.com>
Message-ID: <5526F96D.501@gmx.de>

Thank you for the links.

I knew jeps-200 and jeps-201, but jeps-220 was new for me.

I started a new discussion on the jigsaw-dev mailing list, with a new 
idea for the webstart problem.
Perhaps webstart applications can bring their own jre i.e. use a 
downloaded javafx module from the webserver, instead of the installed 
module.

See:

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-April/004274.html

- Stefan


dalibor topic wrote:
>
>
> On 08.04.2015 23:03, Stefan Fuchs wrote:
>> Anyway I think especially for webstart applications, which have no
>> control over the installed jre should have the possibility to access
>> private apis.
>
> I would suggest reading http://openjdk.java.net/jeps/200 , 
> http://openjdk.java.net/jeps/201 , http://openjdk.java.net/jeps/220 
> and then following the work of the JSR 376 expert group at 
> http://openjdk.java.net/projects/jigsaw/spec/ , starting with 
> http://openjdk.java.net/projects/jigsaw/spec/reqs/02 .
>
> As previously suggested, a better place to discuss general technical 
> aspects of Project Jigsaw would be the jigsaw-dev mailing list.
>
> cheers,
> dalibor topic


From anton.tarasov at oracle.com  Fri Apr 10 10:15:53 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 10 Apr 2015 13:15:53 +0300
Subject: [8u-dev] post-commit notification: RT-40408 NPE in
	javafx.embed.swing.JFXPanel$HostContainer
Message-ID: <5527A2D9.6020105@oracle.com>

A direct backport.

JIRA: https://javafx-jira.kenai.com/browse/RT-40408
Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/22c4ee1d952d

Regards,
Anton.

From anton.tarasov at oracle.com  Fri Apr 10 12:49:20 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Fri, 10 Apr 2015 15:49:20 +0300
Subject: [9] post-commit notification: RT-40496 Expand button becomes invisible
	if there is 'border-radius' defined for <select>
Message-ID: <5527C6D0.70406@oracle.com>

JIRA: https://javafx-jira.kenai.com/browse/RT-40496
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/1db91d13e4f3

Regards,
Anton.

From kevin.rushforth at oracle.com  Fri Apr 10 12:42:01 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Apr 2015 05:42:01 -0700
Subject: [9] post-commit notification: RT-40489 NPE in
	javafx.embed.swing.JFXPanel$HostContainer
In-Reply-To: <55269EB5.60308@oracle.com>
References: <55269EB5.60308@oracle.com>
Message-ID: <5527C519.3000709@oracle.com>


Regarding the changeset for this bug:

> Changeset: ad5669aafe66
> Author:    ant <anton.tarasov at oracle.com>
> Date:      2015-04-09 18:41 +0300
> URL:       http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ad5669aafe66
>
> RT-40489: NPE in javafx.embed.swing.JFXPanel$HostContainer

As a reminder for future changesets, we follow the same policy as JDK: 
backports should use the bug ID of the main JIRA for all code lines. so 
the commit message for this should have been "RT-40408: ...".

-- Kevin


Anton Tarasov wrote:
> JIRA: https://javafx-jira.kenai.com/browse/RT-40489
> Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ad5669aafe66
>
> Regards,
> Anton.

From anton.tarasov at oracle.com  Fri Apr 10 12:50:48 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Fri, 10 Apr 2015 15:50:48 +0300
Subject: [8u-dev] post-commit notification: RT-40461 Expand button becomes
	invisible if there is 'border-radius' defined for <select>
Message-ID: <5527C728.7050606@oracle.com>

A direct backport.

JIRA: https://javafx-jira.kenai.com/browse/RT-40461
Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/96c8d61f9e1c

Regards,
Anton.

From anton.tarasov at oracle.com  Fri Apr 10 12:50:57 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 10 Apr 2015 15:50:57 +0300
Subject: [9] post-commit notification: RT-40489 NPE in
	javafx.embed.swing.JFXPanel$HostContainer
In-Reply-To: <5527C519.3000709@oracle.com>
References: <55269EB5.60308@oracle.com> <5527C519.3000709@oracle.com>
Message-ID: <5527C731.6040405@oracle.com>

On 10.04.2015 15:42, Kevin Rushforth wrote:
>
> Regarding the changeset for this bug:
>
>> Changeset: ad5669aafe66
>> Author:    ant <anton.tarasov at oracle.com>
>> Date:      2015-04-09 18:41 +0300
>> URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ad5669aafe66
>>
>> RT-40489: NPE in javafx.embed.swing.JFXPanel$HostContainer
>
> As a reminder for future changesets, we follow the same policy as JDK: backports should use the 
> bug ID of the main JIRA for all code lines. so the commit message for this should have been 
> "RT-40408: ...".

My apologies, Kevin! Will stick to the rule, thanks for reminding.

Anton.

>
> -- Kevin
>
>
> Anton Tarasov wrote:
>> JIRA: https://javafx-jira.kenai.com/browse/RT-40489
>> Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ad5669aafe66
>>
>> Regards,
>> Anton.


From vadim.pakhnushev at oracle.com  Fri Apr 10 14:30:16 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 10 Apr 2015 17:30:16 +0300
Subject: In(Sanity) Testing Mondays
Message-ID: <5527DE78.9070705@oracle.com>

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PST until 1pm 
PST.

Happy testing!

Thanks,
Vadim

From vadim.pakhnushev at oracle.com  Fri Apr 10 14:32:55 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 10 Apr 2015 17:32:55 +0300
Subject: In(Sanity) Testing Mondays
In-Reply-To: <5527DE78.9070705@oracle.com>
References: <5527DE78.9070705@oracle.com>
Message-ID: <5527DF17.5060709@oracle.com>

On 10.04.2015 17:30, Vadim Pakhnushev wrote:
> Reminder, Monday is our weekly sanity testing.
>
> You can find your testing assignment at:
>
> https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing
>
> Also please remember that the repo will be locked from 1am PST until 
> 1pm PST.

That is, PDT, not PST.

>
> Happy testing!
>
> Thanks,
> Vadim


From kevin.rushforth at oracle.com  Fri Apr 10 16:38:04 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Apr 2015 09:38:04 -0700
Subject: FX JIRA issues with more than one component
Message-ID: <5527FC6C.1020601@oracle.com>

As part of rationalizing our bug database with the JDK, we will no 
longer allow more than one component for any bug in the "RT" project of 
FX JIRA. All bugs should be assigned to a single component.

Please do not add more than one component to any bug when you file it or 
update it.

Thank you.

-- Kevin


From kevin.rushforth at oracle.com  Mon Apr 13 20:11:02 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 13 Apr 2015 13:11:02 -0700
Subject: 8u-dev and 9-dev unlocked following sanity testing <eom>
Message-ID: <552C22D6.3040107@oracle.com>



From johan at lodgon.com  Tue Apr 14 07:10:58 2015
From: johan at lodgon.com (Johan Vos)
Date: Tue, 14 Apr 2015 09:10:58 +0200
Subject: JNI calls in critical sections
Message-ID: <CABek58niRgZKsvKeiORJ5gK=FJijtb1R1uAwzcayJEEVFsvdig@mail.gmail.com>

Hi,

While investigating apparently random crashes on JavaFX mobile
(iOS/Android), I managed to pin one problem down to this:
https://javafx-jira.kenai.com/browse/RT-28705

When something goes wrong loading a JPEG, an error is generated, but
since (*env)->NewStringUTF() is used inside a critical block, this is not
allowed. On recent Android devices, this causes the application to crash.
On iOS, the thread dies.
I have no scientific evidence for this, but I've ran into cases before
where loading a corrupt image on Linux caused no images at all could be
loaded anymore -- but I'm not sure this is related to the same issue.

I see the fix version of RT-28705 is 9, but I'm wondering if the
consequences of this issue aren't bigger than they seem?

- Johan

From kirill.kirichenko at oracle.com  Tue Apr 14 15:36:56 2015
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Tue, 14 Apr 2015 18:36:56 +0300
Subject: [8u60] Request for review: RT-37900: MP3 player fails to exit
Message-ID: <552D3418.8000308@oracle.com>

Hi Alexander.
Could you please review this fix for directshowwrapper.
When working with fuzzed mp3 files decoder->pSrc->DeliverSample fails 
but no error is generated and the whole pipeline just silently swithces 
to prerolling.

webrev: cr.openjdk.java.net/~stayer/RT-37900/
jira: https://javafx-jira.kenai.com/browse/RT-37900

From David.Hill at Oracle.com  Tue Apr 14 15:38:26 2015
From: David.Hill at Oracle.com (David Hill)
Date: Tue, 14 Apr 2015 11:38:26 -0400
Subject: OpenJFX Wiki - on overlays
Message-ID: <552D3472.40304@Oracle.com>


Hi all,
    I just updated the OpenJFX wiki to cover creating the OpenJFX Overlay.

See: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Overlay-JDK8

I certainly would appreciate additional eyes on this section.

Our team has been trying to keep the Wiki up to date and relevant. If you notice anything missing or in need of update, please let us know.

Dave


-- 
David Hill<David.Hill at Oracle.com>
Java Embedded Development

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


From kirill.kirichenko at oracle.com  Tue Apr 14 15:50:51 2015
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Tue, 14 Apr 2015 18:50:51 +0300
Subject: [8u60] Request for review: RT-38022: AIFF player fails to exit
Message-ID: <552D375B.9090508@oracle.com>

Hi Alexander.
Could you please review this fix for aiffparser.c.
When ignoring a chunk of unknown nature the size of the chunk can be of 
MAX_UINT value so flush size is overflown and resets to 0. Upper in the 
callstack we control the offset such that there is no buffer overflow. 
So this is int math problem only. offset is 64 bit already.

webrev: http://cr.openjdk.java.net/~stayer/RT-38022/
jira: https://javafx-jira.kenai.com/browse/RT-38022

From james.graham at oracle.com  Tue Apr 14 19:16:51 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 14 Apr 2015 12:16:51 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>	<5515C483.9030901@oracle.com>	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>	<55199E52.9090503@oracle.com>	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>	<551DCD2F.8080900@oracle.com>
	<5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
Message-ID: <552D67A3.7060004@oracle.com>

Hi Chris,

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

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

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

			...jim

On 4/8/15 9:25 AM, Chris Newland wrote:
> Hi Jim,
>
> I'll post the verbose prism output from my iMac when I get home.
>
> Just tried this on my Linux workstation and the performance gap is the
> same between es2 and sw so I don't think it's an OSX issue.
>
> uname -a
> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>
> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 20
> fps: 31
> fps: 32
> fps: 33
> fps: 35
> fps: 34
> fps: 33
>
> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 54
> fps: 56
> fps: 60
> fps: 59
> fps: 60
> fps: 61
> fps: 61
> fps: 60
>
> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
> graphics card running driver 304.125
>
> Regards,
>
> Chris
>
>
> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>> install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
>> so my theory that something changed in the OGL implementation for 10.10
>> doesn't hold water.
>>
>> But, I then tried it using the integrated graphics.  I get really poor
>> performance using the integrated Intel 4000 graphics, but I get great
>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>> graphics wouldn't be as powerful as the discrete graphics, but we
>> shouldn't be taxing it that much to make that big of a difference.
>>
>> Just to be sure - is that iMac a dual graphics system, or is it
>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>> with -Dprism.verbose=true...
>>
>> ...jim
>>
>>
>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>
>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>> running a newer version of MacOS?
>>>
>>> ...jim
>>>
>>>
>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>
>>>> Hi Herv?,
>>>>
>>>>
>>>> That's a valid question :)
>>>>
>>>>
>>>> Probably because
>>>>
>>>>
>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>> systems
>>>>
>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>> to go for that due to the very large number of nodes.
>>>>
>>>> Numbers for my Sierpinski filled triangle example:
>>>>
>>>>
>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>> 1024 MB
>>>>
>>>>
>>>> java -Dprism.order=es2 -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 23
>>>> fps: 18
>>>> fps: 25
>>>> fps: 18
>>>> fps: 23
>>>> fps: 23
>>>> fps: 19
>>>> fps: 25
>>>>
>>>>
>>>> java -Dprism.order=sw -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 54
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>>
>>>>
>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>> 1.8.0_40
>>>>
>>>>
>>>> I would say there is a performance problem here? (or at least a need
>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>
>>>>> Why don't you use Nodes rather than Canvas ?
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>> <cnewland at chrisnewland.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, that makes things much clearer.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was surprised how much was going on under the hood of
>>>>>> GraphicsContext
>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>> acceleration where available and immediate-mode-like simple
>>>>>> rasterizing where not.
>>>>>>
>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>> so I expect suffers from the problem you've described.
>>>>>>
>>>>>> SSCCE:
>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>> com/ch
>>>>>>
>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>
>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>> JavaFX or
>>>>>> would I be better off with Graphics2D?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>> with a GPU
>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>> with an appropriate shader which is very fast.
>>>>>>>
>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>> like:
>>>>>>>
>>>>>>>
>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>   drawLine() - dealing with only rendering common points of
>>>>>>> intersection once
>>>>>>>
>>>>>>> To handle all of that complexity we have to involve a
>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>> currently for all pipelines.
>>>>>>>
>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>> CPU path
>>>>>>> rasterization.
>>>>>>>
>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>> dominates its performance.
>>>>>>>
>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>
>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>> case. Does
>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>> SW
>>>>>>> pipeline for the polygon case?
>>>>>>>
>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>> calls faster than drawPolygon as well...
>>>>>>>
>>>>>>> ...jim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>> I'd
>>>>>>>> better add my findings.
>>>>>>>>
>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>> strokeLine commands as expected:
>>>>>>>>
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>> Result:
>>>>>>>> 44fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>> Result:
>>>>>>>> 60fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>   examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>
>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>> JavaFX
>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>> do think there's a bug here.
>>>>>>>>
>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>> slow" ;)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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(Op
>>>>>>>>> en%2C% 20%2
>>>>>>>>> 2In%
>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>> 20%20A
>>>>>>>>> ND%2
>>>>>>>>> 0la
>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>
>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>> least OSX and Windows and
>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>
>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>> across diverse platforms"
>>>>>>>>>
>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>> (8u40)
>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>   performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>
>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>> performance that can be tracked?
>>>>>>>>>
>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>> the best.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Possibly related:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>> count) command.
>>>>>>>>>>
>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>
>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Build with ant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Run with:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> # use strokeLine
>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> # use strokePolygon
>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>> 20GB RAM
>>>>>>>>>> /
>>>>>>>>>> Radeon
>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Looking at the code paths in
>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>> than using the convenience method.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>> It is
>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>   predetermined shader, but it shouldn't be that
>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>   AnimationTimer
>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>   serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Robert Kr??ger
>>>>>>>>> Managing Partner
>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> www.lesspain-software.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
>

From kevin.rushforth at oracle.com  Tue Apr 14 19:56:09 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Apr 2015 12:56:09 -0700
Subject: Changes for April 2015 CPU release (8u45) synced into FX 8u
Message-ID: <552D70D9.4030808@oracle.com>

I have synced the OpenJFX changes from the just-released April 2015 CPU 
release (8u45) into 8u (for 8u60) and into 9.

Here is a webrev of the FX 8u45 changes for those who are interested in 
the changes, but don't want to wade through the 47 separate changesets I 
just pushed (most of which are tag or merge changesets).

http://cr.openjdk.java.net/~kcr/8u45-8u-sync/webrev/

The webrev for 9 was identical so I didn't post it.

-- Kevin


From kevin.rushforth at oracle.com  Tue Apr 14 22:20:40 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 14 Apr 2015 15:20:40 -0700
Subject: JavaFX JIRA issues moving to JBS
Message-ID: <552D92B8.4030509@oracle.com>

As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The 
JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK 
Community. With the OpenJFX Project being a part of this Community, it 
is time for us to move away from our separate bug tracker and make use 
of JBS. This will allow us to leverage the greater infrastructure 
investments being made and lessen the burden of having to maintain our 
own infrastructure, and consolidates all JDK bugs in one place. The 
target date for this transition is the second half of May.

The issues currently in the RT project in JavaFX JIRA will be folded 
into the JDK project in JBS. Details will follow on the mapping, but 
here are the highlights:

 - A new "javafx" component will be created in the JDK project
 - Most existing JavaFX JIRA components will be sub-components of the 
"javafx" component
 - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug 
ID will be maintained by JBS such that searching for RT-nnnnn will take 
you to the right JDK-mmmmmmm bug.

A JBS account will be needed to directly report new bugs or comment on 
existing bugs. Most application developers will file new JavaFX bugs at 
bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS 
account [4] is to have a role of Author or higher in an OpenJDK Project 
(e.g., jdk9 or openjfx).

Our advice to those of you actively involved and participating in the 
OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] 
by signing the Oracle Contributor Agreement (OCA) [6]. This is a 
necessary first step in contributing to any OpenJDK Project, including 
OpenJFX. It allows you to provide patches that we might accept for 
OpenJFX, and is also a step along the path to becoming an Author. The 
general guideline [7] is that the Author role may be requested by a 
Project Contributor who has contributed two non-trivial patches that 
have been accepted and pushed.

As part of this transition, we will enable anonymous viewing of bugs (no 
need to login just to look at a bug) and they will be easily searchable 
online.

We apologize for the inconvenience caused to OpenJFX Participants by 
this upcoming change to the bug database write access policy. We really 
appreciate your commitment to improving and growing the JavaFX technology.

-- Kevin


[1] https://javafx-jira.kenai.com/
[2] https://bugs.openjdk.java.net/
[4] https://wiki.openjdk.java.net/display/general/JBS+Overview
[3] http://bugs.java.com/
[5] http://openjdk.java.net/contribute/
[6] http://www.oracle.com/technetwork/oca-405177.pdf
[7] http://openjdk.java.net/projects/#project-author


From neugens.limasoftware at gmail.com  Tue Apr 14 22:23:28 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 15 Apr 2015 00:23:28 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAGUMyaT=DpsVK86mS_mSceO+9w2y9AOYAKwvTkUaW8b4Z2iCdA@mail.gmail.com>

2015-04-15 0:20 GMT+02:00 Kevin Rushforth <kevin.rushforth at oracle.com>:

> As part of this transition, we will enable anonymous viewing of bugs (no
> need to login just to look at a bug) and they will be easily searchable
> online.

Great news!

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From snfuchs at gmx.de  Wed Apr 15 02:58:49 2015
From: snfuchs at gmx.de (Stefan Fuchs)
Date: Wed, 15 Apr 2015 04:58:49 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <552DD3E9.3030100@gmx.de>

Hi Kevin,

while I appreciate the consolidation of the bug tracking systems, I have 
some questions about the JBS.

Having filed some jdk-bugs via bugs.java.com in the past, I never got 
any feedback, if the bug has been accepted and if an JDK bug has been 
created.

For example three weeks ago, I filed a bug about a regression in the 
ssl-engine in the Java 8u60-ea release.
I got an email that the report is evaluated containing a Review ID: 
JI-9020018.
The next day someone from oracle requested unspecified files as 
attachment under the Incident Report 9055609.
I replied that I think, I provided all information needed to reproduce 
the problem and asked about, what specific files he meant.
Since then I never heard anything back.

So my question is, how does the web frontend process work at oracle?
Is there any documentation about it?
Can I somewhere look up the status of an review or incident report?
How I'm supposed to know, that the Review ID and the Incident Report ID 
are related?
(I filed only one bug, so this time it was easy for me)
Will I get information with bug id, if a bug has been created in the JBS?
Will I get an email, if the request has been rejected?
How long does the review process normally take?
Is there an escalation level?


It would be nice, if the initial mail would contain the data from the 
web form, so I could keep it for reference and to verify that all 
information, has been successfully transmitted.


One last question about the migration. I have several bugs on my 
watchlist. Will I continue to receive update notifications for this bugs 
after the migration?


-- Stefan



Kevin Rushforth wrote:
> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. 
> The JDK Bug System [2] (JBS) is the JIRA bug tracker used by the 
> OpenJDK Community. With the OpenJFX Project being a part of this 
> Community, it is time for us to move away from our separate bug 
> tracker and make use of JBS. This will allow us to leverage the 
> greater infrastructure investments being made and lessen the burden of 
> having to maintain our own infrastructure, and consolidates all JDK 
> bugs in one place. The target date for this transition is the second 
> half of May.
>
> The issues currently in the RT project in JavaFX JIRA will be folded 
> into the JDK project in JBS. Details will follow on the mapping, but 
> here are the highlights:
>
> - A new "javafx" component will be created in the JDK project
> - Most existing JavaFX JIRA components will be sub-components of the 
> "javafx" component
> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug 
> ID will be maintained by JBS such that searching for RT-nnnnn will 
> take you to the right JDK-mmmmmmm bug.
>
> A JBS account will be needed to directly report new bugs or comment on 
> existing bugs. Most application developers will file new JavaFX bugs 
> at bugs.java.com [3] just like other JDK bugs. The requirement to get 
> a JBS account [4] is to have a role of Author or higher in an OpenJDK 
> Project (e.g., jdk9 or openjfx).
>
> Our advice to those of you actively involved and participating in the 
> OpenJFX Project is to consider joining the OpenJDK as a Contributor 
> [5] by signing the Oracle Contributor Agreement (OCA) [6]. This is a 
> necessary first step in contributing to any OpenJDK Project, including 
> OpenJFX. It allows you to provide patches that we might accept for 
> OpenJFX, and is also a step along the path to becoming an Author. The 
> general guideline [7] is that the Author role may be requested by a 
> Project Contributor who has contributed two non-trivial patches that 
> have been accepted and pushed.
>
> As part of this transition, we will enable anonymous viewing of bugs 
> (no need to login just to look at a bug) and they will be easily 
> searchable online.
>
> We apologize for the inconvenience caused to OpenJFX Participants by 
> this upcoming change to the bug database write access policy. We 
> really appreciate your commitment to improving and growing the JavaFX 
> technology.
>
> -- Kevin
>
>
> [1] https://javafx-jira.kenai.com/
> [2] https://bugs.openjdk.java.net/
> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [3] http://bugs.java.com/
> [5] http://openjdk.java.net/contribute/
> [6] http://www.oracle.com/technetwork/oca-405177.pdf
> [7] http://openjdk.java.net/projects/#project-author
>
>


From tobi at ultramixer.com  Wed Apr 15 06:32:07 2015
From: tobi at ultramixer.com (Tobias Bley)
Date: Wed, 15 Apr 2015 08:32:07 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <026AE88A-FEED-4D6A-9DF3-A21C63FA3950@ultramixer.com>

Hi,

in my opinion it?s definitely no good news to move from JIRA to JBS. While Jira is a very good and popular bug tracking system, the JDK JBS is a pain. With JBS the community efforts will decrease. It?s too complicated to be part of the Java community if you are forced to first sign a commitment? It?s a step backward :( Like other decisions like stop of SceneBuilder builds, no official mobile ports and so on. Sorry, I?m very disappointed of the current strategy of Oracle.

I still hope that I am wrong?

Best regards,
Tobi


> Am 15.04.2015 um 00:20 schrieb Kevin Rushforth <kevin.rushforth at oracle.com>:
> 
> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. With the OpenJFX Project being a part of this Community, it is time for us to move away from our separate bug tracker and make use of JBS. This will allow us to leverage the greater infrastructure investments being made and lessen the burden of having to maintain our own infrastructure, and consolidates all JDK bugs in one place. The target date for this transition is the second half of May.
> 
> The issues currently in the RT project in JavaFX JIRA will be folded into the JDK project in JBS. Details will follow on the mapping, but here are the highlights:
> 
> - A new "javafx" component will be created in the JDK project
> - Most existing JavaFX JIRA components will be sub-components of the "javafx" component
> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID will be maintained by JBS such that searching for RT-nnnnn will take you to the right JDK-mmmmmmm bug.
> 
> A JBS account will be needed to directly report new bugs or comment on existing bugs. Most application developers will file new JavaFX bugs at bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS account [4] is to have a role of Author or higher in an OpenJDK Project (e.g., jdk9 or openjfx).
> 
> Our advice to those of you actively involved and participating in the OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary first step in contributing to any OpenJDK Project, including OpenJFX. It allows you to provide patches that we might accept for OpenJFX, and is also a step along the path to becoming an Author. The general guideline [7] is that the Author role may be requested by a Project Contributor who has contributed two non-trivial patches that have been accepted and pushed.
> 
> As part of this transition, we will enable anonymous viewing of bugs (no need to login just to look at a bug) and they will be easily searchable online.
> 
> We apologize for the inconvenience caused to OpenJFX Participants by this upcoming change to the bug database write access policy. We really appreciate your commitment to improving and growing the JavaFX technology.
> 
> -- Kevin
> 
> 
> [1] https://javafx-jira.kenai.com/
> [2] https://bugs.openjdk.java.net/
> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [3] http://bugs.java.com/
> [5] http://openjdk.java.net/contribute/
> [6] http://www.oracle.com/technetwork/oca-405177.pdf
> [7] http://openjdk.java.net/projects/#project-author
> 


From ryan at jaeb.ca  Wed Apr 15 06:53:21 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Wed, 15 Apr 2015 00:53:21 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>

Do you guys have an estimate for the percentage of current JIRA
contributors that will no longer be able to participate, in a meaningful
way, in bug reporting due to this change?  I can't speak for anyone else,
but I can tell you what a switch to JBS means to me.

I consider myself an OpenJFX user, not an OpenJFX developer.  I contribute
bug reports, but not patches.  I haven't contributed a ton of bug reports
(22), but every time I run into a bug I take extra time to isolate the
issue, create a reproducible example, and file a bug.  I'm careful to be
polite, honest if I make any mistakes, and I make an effort to follow up
whenever there's activity on a bug I've reported.

The current bug tracker is a good value proposition for me.  My effort has
a direct impact on having bugs that I discover fixed, it's easy for me to
comment on bugs when I feel like I have useful input, I get to vote on all
the bugs that affect me, and, most importantly, the discussion on many bug
reports often leads to an acceptable workaround until the bug can be fixed.

Conversely, contributing via JBS is not a good value proposition for me.  I
won't have an author role, I won't get to comment on bugs, and I won't get
to vote on bugs.  The process for me to participate is more cumbersome and
bureaucratic and is going to be far less meaningful than the participation
that I've become accustomed to with the existing bug tracking system.

Why should I participate in a system where my contributions don't even
warrant a vote on existing bugs?  Once the switch to JBS happens I'll stop
reporting minor bugs.  The hassle of using JBS means I'm only going to make
an effort when I run into a major, showstopping bug.  I don't intend to
sound like I'm throwing a tantrum.  I'm simply being honest.

For a normal user like me, JBS doesn't make contributing easier, it makes
it harder.  It doesn't communicate appreciation to small contributors, it
alienates us.  It's not inviting to new contributors, it's intimidating.
These things may be ok for a large project like the OpenJDK and it may even
help stack the bug tracker with veteran developers.  However, I don't think
JavaFX is in a position to discourage anyone from participating.

Please reconsider the decision to merge with JBS as it's going to have a
significant, negative impact on normal users like me.

Ryan Jaeb


On Tue, Apr 14, 2015 at 4:20 PM, Kevin Rushforth <kevin.rushforth at oracle.com
> wrote:

> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The
> JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK
> Community. With the OpenJFX Project being a part of this Community, it is
> time for us to move away from our separate bug tracker and make use of JBS.
> This will allow us to leverage the greater infrastructure investments being
> made and lessen the burden of having to maintain our own infrastructure,
> and consolidates all JDK bugs in one place. The target date for this
> transition is the second half of May.
>
> The issues currently in the RT project in JavaFX JIRA will be folded into
> the JDK project in JBS. Details will follow on the mapping, but here are
> the highlights:
>
> - A new "javafx" component will be created in the JDK project
> - Most existing JavaFX JIRA components will be sub-components of the
> "javafx" component
> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID
> will be maintained by JBS such that searching for RT-nnnnn will take you to
> the right JDK-mmmmmmm bug.
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx).
>
> Our advice to those of you actively involved and participating in the
> OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by
> signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary
> first step in contributing to any OpenJDK Project, including OpenJFX. It
> allows you to provide patches that we might accept for OpenJFX, and is also
> a step along the path to becoming an Author. The general guideline [7] is
> that the Author role may be requested by a Project Contributor who has
> contributed two non-trivial patches that have been accepted and pushed.
>
> As part of this transition, we will enable anonymous viewing of bugs (no
> need to login just to look at a bug) and they will be easily searchable
> online.
>
> We apologize for the inconvenience caused to OpenJFX Participants by this
> upcoming change to the bug database write access policy. We really
> appreciate your commitment to improving and growing the JavaFX technology.
>
> -- Kevin
>
>
> [1] https://javafx-jira.kenai.com/
> [2] https://bugs.openjdk.java.net/
> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [3] http://bugs.java.com/
> [5] http://openjdk.java.net/contribute/
> [6] http://www.oracle.com/technetwork/oca-405177.pdf
> [7] http://openjdk.java.net/projects/#project-author
>
>

From krueger at lesspain.de  Wed Apr 15 07:26:07 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 15 Apr 2015 09:26:07 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAEnqZEXFRjhi=XCZnsFwWvMstNwYdLByFD6humvM8kQh6kQBwA@mail.gmail.com>

On Wed, Apr 15, 2015 at 12:20 AM, Kevin Rushforth <
kevin.rushforth at oracle.com> wrote:
>
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx)
>

When I submit a bug there, will I be informed of the resulting Jira Issue
ID in JBS? That's crucial for tracking the things I submit. So far I have
perceived bugs.java.com as a black hole compared to the JFX jira.

From Fabrizio.Giudici at tidalwave.it  Wed Apr 15 07:42:50 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 15 Apr 2015 09:42:50 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEnqZEXFRjhi=XCZnsFwWvMstNwYdLByFD6humvM8kQh6kQBwA@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAEnqZEXFRjhi=XCZnsFwWvMstNwYdLByFD6humvM8kQh6kQBwA@mail.gmail.com>
Message-ID: <op.xw4idoxk2ilaq7@wdtvlivehub>

While consolidating the issue tracked is a plus, I share the doubts about  
the usability of JBS vs Jira. Why not going the opposite path :-) that is  
consolidating everything under Jira?

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From tbee at tbee.org  Wed Apr 15 07:49:09 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Wed, 15 Apr 2015 09:49:09 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <op.xw4idoxk2ilaq7@wdtvlivehub>
References: <552D92B8.4030509@oracle.com>	<CAEnqZEXFRjhi=XCZnsFwWvMstNwYdLByFD6humvM8kQh6kQBwA@mail.gmail.com>
	<op.xw4idoxk2ilaq7@wdtvlivehub>
Message-ID: <552E17F5.4030804@tbee.org>

I do not understand these doubts, JBS is Jira?!

https://wiki.openjdk.java.net/display/general/JBS+Overview
/The JDK bug system (JBS) ... is a JIRA instance which provides bug tracking for Projects in the OpenJDK/


On 15-4-2015 09:42, Fabrizio Giudici wrote:
> While consolidating the issue tracked is a plus, I share the doubts about the usability of JBS vs Jira. Why not going the opposite path :-) that is consolidating everything under Jira?
>


From neugens.limasoftware at gmail.com  Wed Apr 15 08:08:49 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 15 Apr 2015 10:08:49 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <026AE88A-FEED-4D6A-9DF3-A21C63FA3950@ultramixer.com>
References: <552D92B8.4030509@oracle.com>
	<026AE88A-FEED-4D6A-9DF3-A21C63FA3950@ultramixer.com>
Message-ID: <CAGUMyaReWaCUvKXAZcntQ4J8SrWF7SNABJPFd5EHvWhEjNu2WQ@mail.gmail.com>

2015-04-15 8:32 GMT+02:00 Tobias Bley <tobi at ultramixer.com>:
> Hi,
>
> in my opinion it?s definitely no good news to move from JIRA to JBS. While Jira is a very good and popular bug tracking system, the JDK JBS is a pain. With JBS the community efforts will decrease. It?s too complicated to be part of the Java community if you are forced to first sign a commitment? It?s a step backward :( Like other decisions like stop of SceneBuilder builds, no official mobile ports and so on. Sorry, I?m very disappointed of the current strategy of Oracle.

JBS for OpenJDK *is* JIRA:

https://bugs.openjdk.java.net/

> I still hope that I am wrong?
>
> Best regards,
> Tobi
>
>
>> Am 15.04.2015 um 00:20 schrieb Kevin Rushforth <kevin.rushforth at oracle.com>:
>>
>> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. With the OpenJFX Project being a part of this Community, it is time for us to move away from our separate bug tracker and make use of JBS. This will allow us to leverage the greater infrastructure investments being made and lessen the burden of having to maintain our own infrastructure, and consolidates all JDK bugs in one place. The target date for this transition is the second half of May.
>>
>> The issues currently in the RT project in JavaFX JIRA will be folded into the JDK project in JBS. Details will follow on the mapping, but here are the highlights:
>>
>> - A new "javafx" component will be created in the JDK project
>> - Most existing JavaFX JIRA components will be sub-components of the "javafx" component
>> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID will be maintained by JBS such that searching for RT-nnnnn will take you to the right JDK-mmmmmmm bug.
>>
>> A JBS account will be needed to directly report new bugs or comment on existing bugs. Most application developers will file new JavaFX bugs at bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS account [4] is to have a role of Author or higher in an OpenJDK Project (e.g., jdk9 or openjfx).
>>
>> Our advice to those of you actively involved and participating in the OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary first step in contributing to any OpenJDK Project, including OpenJFX. It allows you to provide patches that we might accept for OpenJFX, and is also a step along the path to becoming an Author. The general guideline [7] is that the Author role may be requested by a Project Contributor who has contributed two non-trivial patches that have been accepted and pushed.
>>
>> As part of this transition, we will enable anonymous viewing of bugs (no need to login just to look at a bug) and they will be easily searchable online.
>>
>> We apologize for the inconvenience caused to OpenJFX Participants by this upcoming change to the bug database write access policy. We really appreciate your commitment to improving and growing the JavaFX technology.
>>
>> -- Kevin
>>
>>
>> [1] https://javafx-jira.kenai.com/
>> [2] https://bugs.openjdk.java.net/
>> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
>> [3] http://bugs.java.com/
>> [5] http://openjdk.java.net/contribute/
>> [6] http://www.oracle.com/technetwork/oca-405177.pdf
>> [7] http://openjdk.java.net/projects/#project-author
>>
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From Fabrizio.Giudici at tidalwave.it  Wed Apr 15 08:13:13 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 15 Apr 2015 10:13:13 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552E17F5.4030804@tbee.org>
References: <552D92B8.4030509@oracle.com>
	<CAEnqZEXFRjhi=XCZnsFwWvMstNwYdLByFD6humvM8kQh6kQBwA@mail.gmail.com>
	<op.xw4idoxk2ilaq7@wdtvlivehub> <552E17F5.4030804@tbee.org>
Message-ID: <op.xw4jsby52ilaq7@wdtvlivehub>

On Wed, 15 Apr 2015 09:49:09 +0200, Tom Eugelink <tbee at tbee.org> wrote:

> I do not understand these doubts, JBS is Jira?!
>
> https://wiki.openjdk.java.net/display/general/JBS+Overview
> /The JDK bug system (JBS) ... is a JIRA instance which provides bug  
> tracking for Projects in the OpenJDK/

I think that this is clear to everybody. The point is that Jira is  
extremely flexible in configuring access policies and two instances can be  
very different in terms of usability. With Jira/JBS I was referring to the  
two instances and their currently configured access policies. A few people  
pointed out in the previous emails about these differences.

In other words, consolidating to JBS is fine: but, as many expressed  
doubts, does it mean that the JavaFX component will be subject to the same  
configuration of JBS? Or is it possible to have its access policy, as a  
component, to stay the same? What about having the access policy of JBS  
more open, such as the current JIRA for OpenJFX?

I suppose these are more legal issues, or internal Oracle policy issues,  
than technical issues.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From neugens.limasoftware at gmail.com  Wed Apr 15 08:13:35 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 15 Apr 2015 10:13:35 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAGUMyaReWaCUvKXAZcntQ4J8SrWF7SNABJPFd5EHvWhEjNu2WQ@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<026AE88A-FEED-4D6A-9DF3-A21C63FA3950@ultramixer.com>
	<CAGUMyaReWaCUvKXAZcntQ4J8SrWF7SNABJPFd5EHvWhEjNu2WQ@mail.gmail.com>
Message-ID: <CAGUMyaTWoSUJBO=FxYW5ovKhS1V0CP8iryrP0e5wPG+mVp05Sg@mail.gmail.com>

I think the confusing part of Kevin's mail was the "file to bugs.java.com" bit.

I think he meant for customers who already file bugs report to the
shipped-with-Oracle idk version of JavaFX, not the same OpenJFX we
discuss here.

OpenJFX bugs will be directed to the JIRA based https://bugs.openjdk.java.net/

Kevin, is that right, did I understand you correctly?

Cheers,
Mario

2015-04-15 10:08 GMT+02:00 Mario Torre <neugens.limasoftware at gmail.com>:
> 2015-04-15 8:32 GMT+02:00 Tobias Bley <tobi at ultramixer.com>:
>> Hi,
>>
>> in my opinion it?s definitely no good news to move from JIRA to JBS. While Jira is a very good and popular bug tracking system, the JDK JBS is a pain. With JBS the community efforts will decrease. It?s too complicated to be part of the Java community if you are forced to first sign a commitment? It?s a step backward :( Like other decisions like stop of SceneBuilder builds, no official mobile ports and so on. Sorry, I?m very disappointed of the current strategy of Oracle.
>
> JBS for OpenJDK *is* JIRA:
>
> https://bugs.openjdk.java.net/
>
>> I still hope that I am wrong?
>>
>> Best regards,
>> Tobi
>>
>>
>>> Am 15.04.2015 um 00:20 schrieb Kevin Rushforth <kevin.rushforth at oracle.com>:
>>>
>>> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. With the OpenJFX Project being a part of this Community, it is time for us to move away from our separate bug tracker and make use of JBS. This will allow us to leverage the greater infrastructure investments being made and lessen the burden of having to maintain our own infrastructure, and consolidates all JDK bugs in one place. The target date for this transition is the second half of May.
>>>
>>> The issues currently in the RT project in JavaFX JIRA will be folded into the JDK project in JBS. Details will follow on the mapping, but here are the highlights:
>>>
>>> - A new "javafx" component will be created in the JDK project
>>> - Most existing JavaFX JIRA components will be sub-components of the "javafx" component
>>> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID will be maintained by JBS such that searching for RT-nnnnn will take you to the right JDK-mmmmmmm bug.
>>>
>>> A JBS account will be needed to directly report new bugs or comment on existing bugs. Most application developers will file new JavaFX bugs at bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS account [4] is to have a role of Author or higher in an OpenJDK Project (e.g., jdk9 or openjfx).
>>>
>>> Our advice to those of you actively involved and participating in the OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary first step in contributing to any OpenJDK Project, including OpenJFX. It allows you to provide patches that we might accept for OpenJFX, and is also a step along the path to becoming an Author. The general guideline [7] is that the Author role may be requested by a Project Contributor who has contributed two non-trivial patches that have been accepted and pushed.
>>>
>>> As part of this transition, we will enable anonymous viewing of bugs (no need to login just to look at a bug) and they will be easily searchable online.
>>>
>>> We apologize for the inconvenience caused to OpenJFX Participants by this upcoming change to the bug database write access policy. We really appreciate your commitment to improving and growing the JavaFX technology.
>>>
>>> -- Kevin
>>>
>>>
>>> [1] https://javafx-jira.kenai.com/
>>> [2] https://bugs.openjdk.java.net/
>>> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
>>> [3] http://bugs.java.com/
>>> [5] http://openjdk.java.net/contribute/
>>> [6] http://www.oracle.com/technetwork/oca-405177.pdf
>>> [7] http://openjdk.java.net/projects/#project-author
>>>
>>
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From krueger at lesspain.de  Wed Apr 15 08:23:42 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 15 Apr 2015 10:23:42 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
Message-ID: <CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>

On Wed, Apr 15, 2015 at 8:53 AM, Ryan Jaeb <ryan at jaeb.ca> wrote:

> Do you guys have an estimate for the percentage of current JIRA
> contributors that will no longer be able to participate, in a meaningful
> way, in bug reporting due to this change?  I can't speak for anyone else,
> but I can tell you what a switch to JBS means to me.
>
> I consider myself an OpenJFX user, not an OpenJFX developer.  I contribute
> bug reports, but not patches.  I haven't contributed a ton of bug reports
> (22), but every time I run into a bug I take extra time to isolate the
> issue, create a reproducible example, and file a bug.  I'm careful to be
> polite, honest if I make any mistakes, and I make an effort to follow up
> whenever there's activity on a bug I've reported.
>
> The current bug tracker is a good value proposition for me.  My effort has
> a direct impact on having bugs that I discover fixed, it's easy for me to
> comment on bugs when I feel like I have useful input, I get to vote on all
> the bugs that affect me, and, most importantly, the discussion on many bug
> reports often leads to an acceptable workaround until the bug can be fixed.
>
> Conversely, contributing via JBS is not a good value proposition for me.  I
> won't have an author role, I won't get to comment on bugs, and I won't get
> to vote on bugs.  The process for me to participate is more cumbersome and
> bureaucratic and is going to be far less meaningful than the participation
> that I've become accustomed to with the existing bug tracking system.
>
> Why should I participate in a system where my contributions don't even
> warrant a vote on existing bugs?  Once the switch to JBS happens I'll stop
> reporting minor bugs.  The hassle of using JBS means I'm only going to make
> an effort when I run into a major, showstopping bug.  I don't intend to
> sound like I'm throwing a tantrum.  I'm simply being honest.
>
> For a normal user like me, JBS doesn't make contributing easier, it makes
> it harder.  It doesn't communicate appreciation to small contributors, it
> alienates us.  It's not inviting to new contributors, it's intimidating.
> These things may be ok for a large project like the OpenJDK and it may even
> help stack the bug tracker with veteran developers.  However, I don't think
> JavaFX is in a position to discourage anyone from participating.
>
> Please reconsider the decision to merge with JBS as it's going to have a
> significant, negative impact on normal users like me.


I had not realized that I would not be able to comment on my own or other
issues after this change. That is a major step back for me as well and my
role so far is very similar to Ryan's (I have not contributed code but I
have invested considerable amounts of time preparing bug reports with
reproducible test cases and aiding Oracle devs by adding comments when
requested).

So I am totally with Ryan and Tobias on this. Very bad news.

From Fabrizio.Giudici at tidalwave.it  Wed Apr 15 09:13:32 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 15 Apr 2015 11:13:32 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
Message-ID: <op.xw4mkuxy2ilaq7@wdtvlivehub>


> I had not realized that ...

Just be safe that everybody here is aligned to the focus of the  
discussion... As I previously said, I think the problem lies with the  
access policy. From the JBS official page:


********
Account Eligibility
OpenJDK Roles, Groups, and Projects are explained in the OpenJDK Bylaws.  
This JBS guide will use terms defined in the bylaws; the bylaws should be  
consulted for details.

An individual with at least one OpenJDK Project role of Author or higher  
has sufficient cause to get a JBS account. A JBS account grants an  
individual general read and write access to issues, including the ability  
to file new issues, transitioning issues among the states of the workflow,  
adding comments, changing field values (including adding and removing  
labels). The holder of a JBS account can also be the assignee of an issue.

A user's JBS username is his or her OpenJDK name. The password reset page  
can be used both to reset a lost password and to establish a an initial  
password.

At the time of launch, self-service account creation is not supported.  
Users without an account can browse JBS anonymously or use bugs.sun.com to  
view a time-delayed and simplified snapshot of bug state. Users without an  
account can also use bugs.sun.com to submit an issue. When such an issue  
is submitted, a record is created in the Java Incidents (JI) project in  
JBS; at the time of launch, the JI project is not publicly visible. Issues  
in the JI project have an identifier like JI-9XXXXXX, where the numeric  
portion corresponds to the bug identifier sent back to the submitter.  
After an initial triage process, if the incidents needs further review, it  
can be transferred to be an issue in the JDK project. When such a transfer  
occurs, the issue gets a new identifier in the JDK project (JDK-8YYYYYY)  
but references to the original JI-9XXXXXX number will be redirected.
********



There are a few points to discuss, and sure everybody has his own  
priority. For me, one of the most important ones is the capability to  
comment. For instance, today I can go here (issue picked at random)  
https://javafx-jira.kenai.com/browse/RT-30705 and add a comment, because  
perhaps I've run into the issue and I have something to add. If I don't  
have an account, because it's my first time, I can istantly create one at  
Kenai. I have a few customers using JavaFX (as well as many other FLOSS  
projects) and sometimes they run into an issue; I encourage them to  
directly login and report/comment.

 From what I see, JBS still doesn't support self-creation of accounts. I  
don't have one, if I remember well, because I don't have any role in  
OpenJDK projects. For the kind of job I do, that is a consultant focused  
on Java, perhaps I can ask for one and perhaps Oracle would grant one (to  
be verified). But I don't think this would apply for a common employee of  
a corporate that, among other things, also develops in Java; not  
mentioning that not having the possibility of instantly signing in is not  
good, and would discourage almost everybody I know. The "bridge" offered  
by bugs.sun.com is cumbersome too. In any case, this is completely  
different from any other FLOSS project around, where access to the issue  
tracker is immediate and easy.

I think this expands the point that some earlier mentioned about being a  
"user" vs a "developer" of OpenJDK.

I understand that, being Java so popular, Oracle might fear some kind of  
massive, low-level posting of issues, that would be expensive to manage.  
If this is the case, let's discuss it.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From anton.tarasov at oracle.com  Wed Apr 15 09:59:19 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Wed, 15 Apr 2015 12:59:19 +0300
Subject: [9] request for review: RT-37859 VM crash when call a method from
	within javascript code present in a page loaded in webEngine
Message-ID: <552E3677.7090809@oracle.com>

Hi Kevin, Vadim,

Please have a look at the following fix in WebKit bridge/jni/jsc code:

JIRA: https://javafx-jira.kenai.com/browse/RT-37859
webrev: http://cr.openjdk.java.net/~ant/RT-37859/webrev.0

Thanks,
Anton.

From knut.arne.vedaa at broadpark.no  Wed Apr 15 10:05:32 2015
From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa)
Date: Wed, 15 Apr 2015 12:05:32 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <552E37EC.5070007@broadpark.no>

Kevin Rushforth wrote:

> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx).

In my humble opinion this sounds like a very, very bad idea. I could 
rant on, but Ryan Jaeb has described it well and I completely agree with 
him.

Undoubtly, if you go ahead with this, there will be a lot less bug 
reports. You are basically alienating the community.

And it's not just about bugs. If you have to be an author in order to 
comment, this kind of discourse: 
https://javafx-jira.kenai.com/browse/RT-12643 will be a thing of the past.


Knut Arne Vedaa

From adam at adamish.com  Wed Apr 15 11:53:40 2015
From: adam at adamish.com (Adam Granger)
Date: Wed, 15 Apr 2015 10:53:40 -0100
Subject: Updating JavaFX BarChart data causes memory leak?
Message-ID: <d9d84d1f2e4cb1fe878caf5aa635508f.squirrel@webmail.adamish.com>

Hi, I've just asked this on stackoverflow, but I'm guessing someone from
this group might be able to help better... Should I raise a JIRA?

I've discovered what I believe is a memory leak in BarChart triggered by
replacing all the data values in the series. This is exasperated by our
application which does this several times a second.

Using `jvisualvm` shows an uncontrolled growth in the number of
javafx.scene.layout.StackPane instances which eventually results in an
OutOfMemoryError. Styled StackPane nodes are used internally by BarChart
for the bars.

I've tried a different strategies to update the list. All exhibit the same
issue.

    // 1
    series.getData().clear();
    series.getData().addAll(list);
    // 2
    series.getData().setAll(list);
    // 3
    series.setData(list)

Interestingly the example in the BarChart tutorial updates values by
adding all the points first, and then mutating using
XYChart.Data.setYValue(). This could work, but is not convenient for us as
the number of data points can vary dynamically.

Specific questions

 * Is there anyway to avoid this issue, other than a extra logic using the
setYValue() approach above.
 * Have I stumbled across an actual memory leak in JavaFX? or just an
artefact of my misuse of the API? Surely freeing internal nodes when data
is updated is JavaFX responsibility

Example

    public class ChartUpdate extends Application {
        private int clock;
        public static void main(String[] args) {
            launch(args);
        }
        @Override
        public void start(Stage stage) {
            CategoryAxis xAxis = new CategoryAxis();
            NumberAxis yAxis = new NumberAxis(0, 100, 10);
            yAxis.setAutoRanging(false);
            BarChart<String, Number> graph = new BarChart<>(xAxis, yAxis);
            graph.setAnimated(false);
            Series<String, Number> series = new Series<>();
            graph.getData().add(series);
            stage.setScene(new Scene(graph));
            stage.show();

            Timeline timeLine = new Timeline();
            timeLine.getKeyFrames().add(
                    new KeyFrame(Duration.millis(500),
                            (e) -> {
                                ObservableList<Data<String, Number>> list
= FXCollections.observableArrayList();
                                for (int i = 0; i < 100; i++) {
                                    list.add(new Data<>(String.valueOf(i),
(clock + i) % 100));
                                }
                                series.setData(list);
                                clock++;
                            }));
            timeLine.setCycleCount(Animation.INDEFINITE);
            timeLine.play();
        }
    }




From richard.bair at oracle.com  Wed Apr 15 14:54:04 2015
From: richard.bair at oracle.com (Richard Bair)
Date: Wed, 15 Apr 2015 07:54:04 -0700
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <op.xw4mkuxy2ilaq7@wdtvlivehub>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
Message-ID: <ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>

Hi everybody,

Moving to JBS is both good and bad. The good:
Reduce costs associated with the project
Reduce internal overhead for development processes (everybody on Java uses JBS for everything so having a second JIRA makes everything harder with release management, management, even engineers who have to switch from one to the other)
JBS has dedicated engineering for support and maintenance, upgrades, etc
Making OpenJFX more of a core component of OpenJDK
Issues can be indexed on Google etc. (no account required to view issues)

The bad:
Contributing is hard (nay, impossible?) if you are not at least an OpenJDK Author

This last bullet is a huge problem IMO and the reason why we didn?t roll out a migration to JBS 1-2 years ago. But that is an OpenJDK policy issue, and all we can do is raise the issue and voice support for a more lenient policy. I actually don?t know if bugs.java.com <http://bugs.java.com/> allows you to comment on your own bug, but I don?t think it does. What happens if you file a bug and the dev cannot reproduce? Or they need more info? How do you add more info? I?m not even sure this is possible without emailing the engineer directly.

> From what I see, JBS still doesn't support self-creation of accounts.

This is correct. The only way for people to file issues freely is through bugs.java.com

> perhaps I can ask for one and perhaps Oracle would grant one (to be verified).

I am certain you could get one, you?ve been an active member of the community for a long time.

> But I don't think this would apply for a common employee of a corporate that, among other things, also develops in Java; not mentioning that not having the possibility of instantly signing in is not good, and would discourage almost everybody I know. The "bridge" offered by bugs.sun.com is cumbersome too. In any case, this is completely different from any other FLOSS project around, where access to the issue tracker is immediate and easy.

I agree.

> I understand that, being Java so popular, Oracle might fear some kind of massive, low-level posting of issues, that would be expensive to manage. If this is the case, let's discuss it.

This is exactly the issue. We know from the last 20 years that in fact we get a huge amount of completely bogus bugs that get filed via bugs.java.com <http://bugs.java.com/> (previously bugs.sun.com <http://bugs.sun.com/>). Wild stuff from end users like ?I can?t reboot my computer? and so forth. The concern with JBS (as I understand it) was that we?d end up with 10?s or 100,000?s of thousands of user accounts, many of which would be one-shot submitters associated with bogus issues.

One solution would be if Atlasssian had some kind of ?guest? mode where submitter accounts could be created but they would not show up in lists for things like assignees etc so they don?t clutter other views. Another solution could be to have a system whereby anybody who submits a good issue through bugs.java.com <http://bugs.java.com/> would get an email allowing them to sign up on JBS if they had an issue.

Or, maybe the concern is actually not a problem ? since Applets etc would point towards bugs.java.com <http://bugs.java.com/>, the only people (hopefully) coming to JBS are serious developers, the doors could be opened.

Dalibor would probably know the right alias to discuss the JBS policy, and I do believe, personally, that the policy is too restrictive and discourages cooperation and needs to be changed. But I also think moving to JBS is a good thing for a bunch of other reasons (and cost cutting can?t be ignored) and actually I?m looking forward to the ability to browse issues without having to get an account (not like I don?t have an account, but I mean for all the folks out there who just want to see the issues :-)).

Cheers
Richard

From dalibor.topic at oracle.com  Wed Apr 15 15:20:26 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 15 Apr 2015 17:20:26 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
References: <552D92B8.4030509@oracle.com>	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
Message-ID: <552E81BA.2020306@oracle.com>



On 15.04.2015 16:54, Richard Bair wrote:

> Dalibor would probably know the right alias to discuss the JBS policy

Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview :

"General questions about JBS can be sent to discuss at openjdk.java.net.

Feature requests for JBS itself can be sent to ops at openjdk.java.net."

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From dalibor.topic at oracle.com  Wed Apr 15 15:31:31 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 15 Apr 2015 17:31:31 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552DD3E9.3030100@gmx.de>
References: <552D92B8.4030509@oracle.com> <552DD3E9.3030100@gmx.de>
Message-ID: <552E8453.1000204@oracle.com>



On 15.04.2015 04:58, Stefan Fuchs wrote:
> So my question is, how does the web frontend process work at oracle?

Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview

"At the time of launch, self-service account creation is not supported. 
Users without an account can browse JBS anonymously or use bugs.sun.com 
to view a time-delayed and simplified snapshot of bug state. Users 
without an account can also use bugs.sun.com to submit an issue. When 
such an issue is submitted, a record is created in the Java Incidents 
(JI) project in JBS; at the time of launch, the JI project is not 
publicly visible. Issues in the JI project have an identifier like 
JI-9XXXXXX, where the numeric portion corresponds to the bug identifier 
sent back to the submitter. After an initial triage process, if the 
incidents needs further review, it can be transferred to be an issue in 
the JDK project. When such a transfer occurs, the issue gets a new 
identifier in the JDK project (JDK-8YYYYYY) but references to the 
original JI-9XXXXXX number will be redirected."

> Can I somewhere look up the status of an review or incident report?

You can browse to https://bugs.openjdk.java.net/browse/JI-9XXXXXX and if 
an incident report has been triaged and transferred, you will be 
redirected to https://bugs.openjdk.java.net/browse/JDK-8YYYYYY .

> Is there an escalation level?

Quoting from http://bugs.java.com/ :

"Please note that fixes for bug reports are not guaranteed through this 
channel.
For bugs that require immediate and personal attention, Oracle offers 
Java SE
Support. Support customers should report bugs through My Oracle Support. "

> One last question about the migration. I have several bugs on my
> watchlist. Will I continue to receive update notifications for this bugs
> after the migration?

See https://robilad.livejournal.com/139637.html

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From krueger at lesspain.de  Wed Apr 15 15:55:19 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Wed, 15 Apr 2015 17:55:19 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
Message-ID: <CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>

On Wed, Apr 15, 2015 at 4:54 PM, Richard Bair <richard.bair at oracle.com>
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>


> The bad:
>
>    - Contributing is hard (nay, impossible?) if you are not at least an
>    OpenJDK Author
>
>
>
That's really the only (and serious) aspect anyone is complaining about
IIRC. Having everything in one Jira instance does of course make sense.


> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> ?I can?t reboot my computer? and so forth. The concern with JBS (as I
> understand it) was that we?d end up with 10?s or 100,000?s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
>
Understandable. IMHO a certain "seriousness threshold" to reduce the noise
makes sense. What if you at least had a policy where someone in your team
can propose people they know from the mailing list for a while for
accounts? I don't think what's needed is to have a completely open system
with one-click self-registration but don't draw the line where you draw it
now, which means you're missing qualified input from people who are ready
to invest qualified time (e.g. to build test cases and good descriptions of
issues) but do not submit patches.


> One solution would be if Atlasssian had some kind of ?guest? mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don?t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>

Yes, something like that would address at least my concerns.


>
> Or, maybe the concern is actually not a problem ? since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can?t be
> ignored) and actually I?m looking forward to the ability to browse issues
> without having to get an account (not like I don?t have an account, but I
> mean for all the folks out there who just want to see the issues :-)).
>
>
Your response gives me some hope that you take the feedback seriously. This
is a big thing. Please don't disappoint us by letting this discussion fade
into nirvana without anything being done about that.

From ryan at jaeb.ca  Wed Apr 15 15:55:37 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Wed, 15 Apr 2015 09:55:37 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
Message-ID: <CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>

Keep in mind the cost cutting is going to be exaggerated and it's going to
be difficult to measure any long term damage this change will have on the
JavaFX community.  People like me are going to stop participating.
There'll be fewer bug reports, it's going to take fewer people to manage
the bug load, and fewer developers to fix bugs.  Of course that's going to
translate into additional savings.  Plus, someone's going to get praised
for cutting costs while improving reliability.  The reality is JavaFX will
end up with more undiscovered bugs.

Why can't an effort be made to influence JBS policies before making the
switch?  My concern is that once the cost savings of the switch have been
realized, there's going to be no incentive to re-include people like me.  I
completely understand the justification for merging with JBS, but I'm
extremely frustrated that Oracle hasn't considered the impact an immediate
switch will have on the community.  This is a predictable transition and
there's no excuse for failing to come up with a solution that doesn't
alienate existing participants before making the change.

Ryan Jaeb


On Wed, Apr 15, 2015 at 8:54 AM, Richard Bair <richard.bair at oracle.com>
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>
>    - Reduce costs associated with the project
>    - Reduce internal overhead for development processes (everybody on
>    Java uses JBS for everything so having a second JIRA makes everything
>    harder with release management, management, even engineers who have to
>    switch from one to the other)
>    - JBS has dedicated engineering for support and maintenance, upgrades,
>    etc
>    - Making OpenJFX more of a core component of OpenJDK
>    - Issues can be indexed on Google etc. (no account required to view
>    issues)
>
>
> The bad:
>
>    - Contributing is hard (nay, impossible?) if you are not at least an
>    OpenJDK Author
>
>
> This last bullet is a huge problem IMO and the reason why we didn?t roll
> out a migration to JBS 1-2 years ago. But that is an OpenJDK policy issue,
> and all we can do is raise the issue and voice support for a more lenient
> policy. I actually don?t know if bugs.java.com allows you to comment on
> your own bug, but I don?t think it does. What happens if you file a bug and
> the dev cannot reproduce? Or they need more info? How do you add more info?
> I?m not even sure this is possible without emailing the engineer directly.
>
> From what I see, JBS still doesn't support self-creation of accounts.
>
>
> This is correct. The only way for people to file issues freely is through
> bugs.java.com
>
> perhaps I can ask for one and perhaps Oracle would grant one (to be
> verified).
>
>
> I am certain you could get one, you?ve been an active member of the
> community for a long time.
>
> But I don't think this would apply for a common employee of a corporate
> that, among other things, also develops in Java; not mentioning that not
> having the possibility of instantly signing in is not good, and would
> discourage almost everybody I know. The "bridge" offered by bugs.sun.com
> is cumbersome too. In any case, this is completely different from any other
> FLOSS project around, where access to the issue tracker is immediate and
> easy.
>
>
> I agree.
>
> I understand that, being Java so popular, Oracle might fear some kind of
> massive, low-level posting of issues, that would be expensive to manage. If
> this is the case, let's discuss it.
>
>
> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> ?I can?t reboot my computer? and so forth. The concern with JBS (as I
> understand it) was that we?d end up with 10?s or 100,000?s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
> One solution would be if Atlasssian had some kind of ?guest? mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don?t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>
> Or, maybe the concern is actually not a problem ? since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can?t be
> ignored) and actually I?m looking forward to the ability to browse issues
> without having to get an account (not like I don?t have an account, but I
> mean for all the folks out there who just want to see the issues :-)).
>
> Cheers
> Richard
>

From rdarrylr at gmail.com  Wed Apr 15 16:00:25 2015
From: rdarrylr at gmail.com (Darryl R)
Date: Wed, 15 Apr 2015 16:00:25 +0000 (UTC)
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
Message-ID: <891C291C8AD7CE60.44A03B24-0DDD-441E-A43B-C3C36FD6C6A5@mail.outlook.com>

What are the chances more open access policies will really be implemented? It sounds to me like they really won't so it will cut off input from most people. Costs will go down yes but unreported bugs will go up and users will have much less sense of really being involved.






On Wed, Apr 15, 2015 at 8:57 AM -0700, "Ryan Jaeb" <ryan at jaeb.ca> wrote:










Keep in mind the cost cutting is going to be exaggerated and it's going to
be difficult to measure any long term damage this change will have on the
JavaFX community.  People like me are going to stop participating.
There'll be fewer bug reports, it's going to take fewer people to manage
the bug load, and fewer developers to fix bugs.  Of course that's going to
translate into additional savings.  Plus, someone's going to get praised
for cutting costs while improving reliability.  The reality is JavaFX will
end up with more undiscovered bugs.

Why can't an effort be made to influence JBS policies before making the
switch?  My concern is that once the cost savings of the switch have been
realized, there's going to be no incentive to re-include people like me.  I
completely understand the justification for merging with JBS, but I'm
extremely frustrated that Oracle hasn't considered the impact an immediate
switch will have on the community.  This is a predictable transition and
there's no excuse for failing to come up with a solution that doesn't
alienate existing participants before making the change.

Ryan Jaeb


On Wed, Apr 15, 2015 at 8:54 AM, Richard Bair 
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>
>    - Reduce costs associated with the project
>    - Reduce internal overhead for development processes (everybody on
>    Java uses JBS for everything so having a second JIRA makes everything
>    harder with release management, management, even engineers who have to
>    switch from one to the other)
>    - JBS has dedicated engineering for support and maintenance, upgrades,
>    etc
>    - Making OpenJFX more of a core component of OpenJDK
>    - Issues can be indexed on Google etc. (no account required to view
>    issues)
>
>
> The bad:
>
>    - Contributing is hard (nay, impossible?) if you are not at least an
>    OpenJDK Author
>
>
> This last bullet is a huge problem IMO and the reason why we didn?t roll
> out a migration to JBS 1-2 years ago. But that is an OpenJDK policy issue,
> and all we can do is raise the issue and voice support for a more lenient
> policy. I actually don?t know if bugs.java.com allows you to comment on
> your own bug, but I don?t think it does. What happens if you file a bug and
> the dev cannot reproduce? Or they need more info? How do you add more info?
> I?m not even sure this is possible without emailing the engineer directly.
>
> From what I see, JBS still doesn't support self-creation of accounts.
>
>
> This is correct. The only way for people to file issues freely is through
> bugs.java.com
>
> perhaps I can ask for one and perhaps Oracle would grant one (to be
> verified).
>
>
> I am certain you could get one, you?ve been an active member of the
> community for a long time.
>
> But I don't think this would apply for a common employee of a corporate
> that, among other things, also develops in Java; not mentioning that not
> having the possibility of instantly signing in is not good, and would
> discourage almost everybody I know. The "bridge" offered by bugs.sun.com
> is cumbersome too. In any case, this is completely different from any other
> FLOSS project around, where access to the issue tracker is immediate and
> easy.
>
>
> I agree.
>
> I understand that, being Java so popular, Oracle might fear some kind of
> massive, low-level posting of issues, that would be expensive to manage. If
> this is the case, let's discuss it.
>
>
> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> ?I can?t reboot my computer? and so forth. The concern with JBS (as I
> understand it) was that we?d end up with 10?s or 100,000?s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
> One solution would be if Atlasssian had some kind of ?guest? mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don?t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>
> Or, maybe the concern is actually not a problem ? since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can?t be
> ignored) and actually I?m looking forward to the ability to browse issues
> without having to get an account (not like I don?t have an account, but I
> mean for all the folks out there who just want to see the issues :-)).
>
> Cheers
> Richard
>

From Fabrizio.Giudici at tidalwave.it  Wed Apr 15 16:03:14 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 15 Apr 2015 18:03:14 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>
Message-ID: <op.xw45joi42ilaq7@wdtvlivehub>

On Wed, 15 Apr 2015 17:55:19 +0200, Robert Kr?ger <krueger at lesspain.de>  
wrote:

> Understandable. IMHO a certain "seriousness threshold" to reduce the  
> noise
> makes sense.

I was thinking on a score system such as the one at StackOverflow, but I'm  
not aware of any support of Atlassian.

> What if you at least had a policy where someone in your team
> can propose people they know from the mailing list for a while for
> accounts? I don't think what's needed is to have a completely open system
> with one-click self-registration but don't draw the line where you draw  
> it
> now, which means you're missing qualified input from people who are ready
> to invest qualified time (e.g. to build test cases and good descriptions  
> of
> issues) but do not submit patches.

I would add that having a corporate collective account could probably  
help. I'm thinking of a case in which there are a couple of dozen  
developers from the same corporate that could share the same email alias.  
Even in this case self-subscribing wouldn't be needed, actually it might  
make sense to have a control process to be sure that the corporate account  
is official, I mean the corporate is in charge for it.


-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From ryan at jaeb.ca  Wed Apr 15 16:31:56 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Wed, 15 Apr 2015 10:31:56 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <op.xw45joi42ilaq7@wdtvlivehub>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>
	<op.xw45joi42ilaq7@wdtvlivehub>
Message-ID: <CAOrfuJ2sGBeOvf7UepirfHpLMozzcgy-nwjzJfGCJhXHcrDLig@mail.gmail.com>

I will also add a suggestion that I think would be reasonable.  Take
advantage of the OTN forum.  Anyone without a JBS account could be asked to
post their first bug report to the forum.  If it's not a bug, the forum
community can help with the issue.  The forum community can also help
people learn to write a good bug report.

If someone submits a decent quality bug report to the forum, they could be
invited to use JBA.  The threshold could be more than one good bug report
to the forum if needed.  That gives new users and entry point into the
community and it filters out most of the noise on the actual bug tracker.

You could probably even come up with a strategy for letting the community
nominate people for JBS invites so the developers wouldn't have to sift
through the forums looking for users that would make good JBS participants.

Ryan Jaeb



On Wed, Apr 15, 2015 at 10:03 AM, Fabrizio Giudici <
Fabrizio.Giudici at tidalwave.it> wrote:

> On Wed, 15 Apr 2015 17:55:19 +0200, Robert Kr?ger <krueger at lesspain.de>
> wrote:
>
>  Understandable. IMHO a certain "seriousness threshold" to reduce the noise
>> makes sense.
>>
>
> I was thinking on a score system such as the one at StackOverflow, but I'm
> not aware of any support of Atlassian.
>
>  What if you at least had a policy where someone in your team
>> can propose people they know from the mailing list for a while for
>> accounts? I don't think what's needed is to have a completely open system
>> with one-click self-registration but don't draw the line where you draw it
>> now, which means you're missing qualified input from people who are ready
>> to invest qualified time (e.g. to build test cases and good descriptions
>> of
>> issues) but do not submit patches.
>>
>
> I would add that having a corporate collective account could probably
> help. I'm thinking of a case in which there are a couple of dozen
> developers from the same corporate that could share the same email alias.
> Even in this case self-subscribing wouldn't be needed, actually it might
> make sense to have a control process to be sure that the corporate account
> is official, I mean the corporate is in charge for it.
>
>
> --
> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
> "We make Java work. Everywhere."
> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it
>

From Fabrizio.Giudici at tidalwave.it  Wed Apr 15 16:44:25 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 15 Apr 2015 18:44:25 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ2sGBeOvf7UepirfHpLMozzcgy-nwjzJfGCJhXHcrDLig@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>
	<op.xw45joi42ilaq7@wdtvlivehub>
	<CAOrfuJ2sGBeOvf7UepirfHpLMozzcgy-nwjzJfGCJhXHcrDLig@mail.gmail.com>
Message-ID: <op.xw47cvxp2ilaq7@wdtvlivehub>

On Wed, 15 Apr 2015 18:31:56 +0200, Ryan Jaeb <ryan at jaeb.ca> wrote:


> If someone submits a decent quality bug report to the forum, they could  
> be
> invited to use JBA. ...
> You could probably even come up with a strategy for letting the community
> nominate people for JBS invites so the developers wouldn't have to sift
> through the forums looking for users that would make good JBS  
> participants.

Good points.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From jonathan.giles at oracle.com  Wed Apr 15 20:49:11 2015
From: jonathan.giles at oracle.com (Jonathan Giles)
Date: Thu, 16 Apr 2015 08:49:11 +1200
Subject: Updating JavaFX BarChart data causes memory leak?
In-Reply-To: <d9d84d1f2e4cb1fe878caf5aa635508f.squirrel@webmail.adamish.com>
References: <d9d84d1f2e4cb1fe878caf5aa635508f.squirrel@webmail.adamish.com>
Message-ID: <552ECEC7.2070800@oracle.com>

You don't mention what version of JavaFX you are using. Assuming you 
have tested this issue against 8u40 and / or 8u60 EA builds, and if the 
issue persists, then yes, please file an issue in Jira.

Thanks,

-- Jonathan

On 15/04/2015 11:53 p.m., Adam Granger wrote:
> Hi, I've just asked this on stackoverflow, but I'm guessing someone from
> this group might be able to help better... Should I raise a JIRA?
>
> I've discovered what I believe is a memory leak in BarChart triggered by
> replacing all the data values in the series. This is exasperated by our
> application which does this several times a second.
>
> Using `jvisualvm` shows an uncontrolled growth in the number of
> javafx.scene.layout.StackPane instances which eventually results in an
> OutOfMemoryError. Styled StackPane nodes are used internally by BarChart
> for the bars.
>
> I've tried a different strategies to update the list. All exhibit the same
> issue.
>
>      // 1
>      series.getData().clear();
>      series.getData().addAll(list);
>      // 2
>      series.getData().setAll(list);
>      // 3
>      series.setData(list)
>
> Interestingly the example in the BarChart tutorial updates values by
> adding all the points first, and then mutating using
> XYChart.Data.setYValue(). This could work, but is not convenient for us as
> the number of data points can vary dynamically.
>
> Specific questions
>
>   * Is there anyway to avoid this issue, other than a extra logic using the
> setYValue() approach above.
>   * Have I stumbled across an actual memory leak in JavaFX? or just an
> artefact of my misuse of the API? Surely freeing internal nodes when data
> is updated is JavaFX responsibility
>
> Example
>
>      public class ChartUpdate extends Application {
>          private int clock;
>          public static void main(String[] args) {
>              launch(args);
>          }
>          @Override
>          public void start(Stage stage) {
>              CategoryAxis xAxis = new CategoryAxis();
>              NumberAxis yAxis = new NumberAxis(0, 100, 10);
>              yAxis.setAutoRanging(false);
>              BarChart<String, Number> graph = new BarChart<>(xAxis, yAxis);
>              graph.setAnimated(false);
>              Series<String, Number> series = new Series<>();
>              graph.getData().add(series);
>              stage.setScene(new Scene(graph));
>              stage.show();
>
>              Timeline timeLine = new Timeline();
>              timeLine.getKeyFrames().add(
>                      new KeyFrame(Duration.millis(500),
>                              (e) -> {
>                                  ObservableList<Data<String, Number>> list
> = FXCollections.observableArrayList();
>                                  for (int i = 0; i < 100; i++) {
>                                      list.add(new Data<>(String.valueOf(i),
> (clock + i) % 100));
>                                  }
>                                  series.setData(list);
>                                  clock++;
>                              }));
>              timeLine.setCycleCount(Animation.INDEFINITE);
>              timeLine.play();
>          }
>      }
>
>
>


From james.graham at oracle.com  Wed Apr 15 21:01:46 2015
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 15 Apr 2015 14:01:46 -0700
Subject: [9, 8u60] review request for RT-40533 - rendering overhead for small
	shapes in Canvas
Message-ID: <552ED1BA.6070407@oracle.com>

Jira: https://javafx-jira.kenai.com/browse/RT-40533
webrev: http://cr.openjdk.java.net/~flar/RT-40533/webrev.02/

(note that this latest webrev is generated against 9-dev and has a few 
lines/names/copyrights cleaned up, but no change in the logic...)

			...jim

From richard.bair at oracle.com  Thu Apr 16 00:24:13 2015
From: richard.bair at oracle.com (Richard Bair)
Date: Wed, 15 Apr 2015 17:24:13 -0700
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
Message-ID: <F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>

> Why can't an effort be made to influence JBS policies before making the switch?

I think the way to do this is to engage the JBS folks on their alias, I don?t think they watch this one and Kevin doesn?t have the ability to change this policy. He?s just the messenger!

Richard

From ryan at jaeb.ca  Thu Apr 16 01:56:54 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Wed, 15 Apr 2015 19:56:54 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
Message-ID: <CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>

My frustration isn't aimed at anyone on the list, so I hope it didn't seem
like that.

I don't usually post to the list, but I follow it enough to know that, once
we see an announcement like the one Kevin delivered, the decision has been
made and there's no going back.  If I've misinterpreted, I apologize.
Please correct me.

The thing that's particularly frustrating with this incident is that it's
going to have a predictable, negative impact on people like me who feel
like submitting bug reports is the most effect contribution we can make to
the JavaFX community.  Being told that we should engage the JBS folks after
the decision has been made isn't acceptable.  Whoever made the decision to
merge with JBS should already have engaged the JBS folks and advocated for
changes on behalf of the JavaFX community before the decision was
finalized.  The message Kevin delivered should have included the results of
that advocacy.

Regardless, what's done is done.  If we need to have someone engage the JBS
people to ask for policy changes, I think we'd do well to nominate whoever
made the original decision.  If they have enough influence to get a project
merged into the JBS, they're effort will be far more effective than that of
a random person from the community.

We've been told that Oracle wants to see more participation from the JavaFX
community.  This is an excellent opportunity for someone with a decision
making role at Oracle to take action and demonstrate to the community that
they're willing to help facilitate some of that participation.

Ryan Jaeb

On Wed, Apr 15, 2015 at 6:24 PM, Richard Bair <richard.bair at oracle.com>
wrote:

> > Why can't an effort be made to influence JBS policies before making the
> switch?
>
> I think the way to do this is to engage the JBS folks on their alias, I
> don?t think they watch this one and Kevin doesn?t have the ability to
> change this policy. He?s just the messenger!
>
> Richard

From powers.anirvan at gmail.com  Thu Apr 16 06:01:59 2015
From: powers.anirvan at gmail.com (Anirvan Sarkar)
Date: Thu, 16 Apr 2015 11:31:59 +0530
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAEQxcvGMNiArPPXWEhQ6veKBAngL2sLeyvhK00RALF7qxfkdCA@mail.gmail.com>

On 15 April 2015 at 03:50, Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> ...
> The issues currently in the RT project in JavaFX JIRA will be folded into
> the JDK project in JBS.
>

What about the Scene Builder issues (DTL project in JavaFX JIRA)? Would
they also be migrated to JBS?

-- 
Anirvan

From adam at adamish.com  Thu Apr 16 06:20:40 2015
From: adam at adamish.com (Adam Granger)
Date: Thu, 16 Apr 2015 05:20:40 -0100
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ2sGBeOvf7UepirfHpLMozzcgy-nwjzJfGCJhXHcrDLig@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAEnqZEVfva=8pOExQnOhjnRuWxavhFWd2vKYxktx3WhXYzNYFA@mail.gmail.com>
	<op.xw45joi42ilaq7@wdtvlivehub>
	<CAOrfuJ2sGBeOvf7UepirfHpLMozzcgy-nwjzJfGCJhXHcrDLig@mail.gmail.com>
Message-ID: <05bdde41de0b66c84384a77b0d8a3116.squirrel@webmail.adamish.com>

A crazy out-there suggestion...

Could OpenJDK work in partnership with stackoverflow on this through via
either a new tag - e.g.[javafx-possible-bug] or a whole new stackoverflow
site?

IMHO forums aren't the best way to work through coding problems, it's just
unorganised noise, the stackoverflow structured
question/answer/comment/vote approach is much better suited.... poor
quality questions (bug reports) will automatically get culled by the
crowd, sscce questions are encouraged, better community involvement
etc....

Adam.

> I will also add a suggestion that I think would be reasonable.  Take
> advantage of the OTN forum.  Anyone without a JBS account could be asked
> to
> post their first bug report to the forum.  If it's not a bug, the forum
> community can help with the issue.  The forum community can also help
> people learn to write a good bug report.
>
> If someone submits a decent quality bug report to the forum, they could be
> invited to use JBA.  The threshold could be more than one good bug report
> to the forum if needed.  That gives new users and entry point into the
> community and it filters out most of the noise on the actual bug tracker.
>
> You could probably even come up with a strategy for letting the community
> nominate people for JBS invites so the developers wouldn't have to sift
> through the forums looking for users that would make good JBS
> participants.
>
> Ryan Jaeb
>
>
>
> On Wed, Apr 15, 2015 at 10:03 AM, Fabrizio Giudici <
> Fabrizio.Giudici at tidalwave.it> wrote:
>
>> On Wed, 15 Apr 2015 17:55:19 +0200, Robert Kr??ger <krueger at lesspain.de>
>> wrote:
>>
>>  Understandable. IMHO a certain "seriousness threshold" to reduce the
>> noise
>>> makes sense.
>>>
>>
>> I was thinking on a score system such as the one at StackOverflow, but
>> I'm
>> not aware of any support of Atlassian.
>>
>>  What if you at least had a policy where someone in your team
>>> can propose people they know from the mailing list for a while for
>>> accounts? I don't think what's needed is to have a completely open
>>> system
>>> with one-click self-registration but don't draw the line where you draw
>>> it
>>> now, which means you're missing qualified input from people who are
>>> ready
>>> to invest qualified time (e.g. to build test cases and good
>>> descriptions
>>> of
>>> issues) but do not submit patches.
>>>
>>
>> I would add that having a corporate collective account could probably
>> help. I'm thinking of a case in which there are a couple of dozen
>> developers from the same corporate that could share the same email
>> alias.
>> Even in this case self-subscribing wouldn't be needed, actually it might
>> make sense to have a control process to be sure that the corporate
>> account
>> is official, I mean the corporate is in charge for it.
>>
>>
>> --
>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
>> "We make Java work. Everywhere."
>> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it
>>
>



From krueger at lesspain.de  Thu Apr 16 07:33:51 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 16 Apr 2015 09:33:51 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>
Message-ID: <CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>

On Thursday, April 16, 2015, Ryan Jaeb <ryan at jaeb.ca> wrote:

> My frustration isn't aimed at anyone on the list, so I hope it didn't seem
> like that.
>
> I don't usually post to the list, but I follow it enough to know that, once
> we see an announcement like the one Kevin delivered, the decision has been
> made and there's no going back.  If I've misinterpreted, I apologize.
> Please correct me.
>
> The thing that's particularly frustrating with this incident is that it's
> going to have a predictable, negative impact on people like me who feel
> like submitting bug reports is the most effect contribution we can make to
> the JavaFX community.  Being told that we should engage the JBS folks after
> the decision has been made isn't acceptable.  Whoever made the decision to
> merge with JBS should already have engaged the JBS folks and advocated for
> changes on behalf of the JavaFX community before the decision was
> finalized.  The message Kevin delivered should have included the results of
> that advocacy.
>
> Regardless, what's done is done.  If we need to have someone engage the JBS
> people to ask for policy changes, I think we'd do well to nominate whoever
> made the original decision.  If they have enough influence to get a project
> merged into the JBS, they're effort will be far more effective than that of
> a random person from the community.
>
> We've been told that Oracle wants to see more participation from the JavaFX
> community.  This is an excellent opportunity for someone with a decision
> making role at Oracle to take action and demonstrate to the community that
> they're willing to help facilitate some of that participation.
>
>
Amen to every single aspect you touch. I believe that summarizes pretty
well how many of us die-hard java desktop/client-side application/product
developers feel.

@Dalibor: An after-the-fact "Not our responsibility, ask over there" is not
exactly how you get your community to feel involved. But Ryan has also
already covered that very well above.

From cnewland at chrisnewland.com  Thu Apr 16 08:39:45 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Thu, 16 Apr 2015 09:39:45 +0100
Subject: Canvas performance on Mac OS
In-Reply-To: <552D67A3.7060004@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
Message-ID: <3eda52657ce2df280ee4f1893469516d.squirrel@excalibur.xssl.net>

Hi Jim,

Thanks for looking into this.

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

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

Will test on OSX tonight.

Cheers,

Chris


On Tue, April 14, 2015 20:16, Jim Graham wrote:
> Hi Chris,
>
>
> We identified a fairly localized optimization that we might be able to
> apply to enhance the performance of your Sierpinski program.  We don't have
> any figures yet on whether this will improve other applications/benchmarks
> that people have been discussing, but the improvements with your
> Sierpinski program are quite dramatic on a number
> of platforms and GPUs.
>
> This issue is now being tracked as:
> https://javafx-jira.kenai.com/browse/RT-40533
>
>
> If others could apply the indicated patch to an OpenJFX build and
> provide feedback on any improvements (or bugs!) that they see, that would
> help.  In the meantime, we have a lot of testing to do to verify the
> correctness of the changes...
>
> ...jim
>
>
> On 4/8/15 9:25 AM, Chris Newland wrote:
>
>> Hi Jim,
>>
>>
>> I'll post the verbose prism output from my iMac when I get home.
>>
>>
>> Just tried this on my Linux workstation and the performance gap is the
>> same between es2 and sw so I don't think it's an OSX issue.
>>
>> uname -a Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64
>> GNU/Linux
>>
>>
>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>> fps: 20
>> fps: 31
>> fps: 32
>> fps: 33
>> fps: 35
>> fps: 34
>> fps: 33
>>
>>
>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>> fps: 54
>> fps: 56
>> fps: 60
>> fps: 59
>> fps: 60
>> fps: 61
>> fps: 61
>> fps: 60
>>
>>
>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>> graphics card running driver 304.125
>>
>> Regards,
>>
>>
>> Chris
>>
>>
>>
>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>
>>> OK, I took the time to put my rMBP on a diet yesterday and find room
>>> to install a 10.10 partition.  I get the same numbers for Sierpinski
>>> on 10.10, so my theory that something changed in the OGL
>>> implementation for 10.10 doesn't hold water.
>>>
>>> But, I then tried it using the integrated graphics.  I get really
>>> poor performance using the integrated Intel 4000 graphics, but I get
>>> great numbers on the discrete nVidia 650m.  It makes sense that the
>>> Intel
>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>> shouldn't be taxing it that much to make that big of a difference.
>>>
>>> Just to be sure - is that iMac a dual graphics system, or is it
>>> all-AMD-all-the-time?  You can see which GPU is being used if you run
>>> it with -Dprism.verbose=true...
>>>
>>> ...jim
>>>
>>>
>>>
>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>
>>>
>>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are
>>>> you running a newer version of MacOS?
>>>>
>>>> ...jim
>>>>
>>>>
>>>>
>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>
>>>>
>>>>> Hi Herv?,
>>>>>
>>>>>
>>>>>
>>>>> That's a valid question :)
>>>>>
>>>>>
>>>>>
>>>>> Probably because
>>>>>
>>>>>
>>>>>
>>>>> a) All my non-UI graphics experience is with immediate-mode /
>>>>> raster systems
>>>>>
>>>>> b) I'm interested in using JavaFX for particle effects /
>>>>> demoscene / gaming so assumed (perhaps wrongly?) that scenegraph
>>>>> was not the way to go for that due to the very large number of
>>>>> nodes.
>>>>>
>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>
>>>>>
>>>>>
>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>>  1024 MB
>>>>>
>>>>>
>>>>>
>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23
>>>>> fps: 18
>>>>> fps: 25
>>>>> fps: 18
>>>>> fps: 23
>>>>> fps: 23
>>>>> fps: 19
>>>>> fps: 25
>>>>>
>>>>>
>>>>>
>>>>> java -Dprism.order=sw -cp target/classes/
>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>>
>>>>>
>>>>>
>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>>  1.8.0_40
>>>>>
>>>>>
>>>>>
>>>>> I would say there is a performance problem here? (or at least a
>>>>> need for documentation so as to set expectations for
>>>>> gc.fillPolygon).
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>
>>>>>
>>>>>> Why don't you use Nodes rather than Canvas ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>> <cnewland at chrisnewland.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks, that makes things much clearer.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I was surprised how much was going on under the hood of
>>>>>>> GraphicsContext
>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>> rasterizing where not.
>>>>>>>
>>>>>>> I've managed to find an anomaly with
>>>>>>> GraphicsContext.fillPolygon
>>>>>>> where the software pipeline achieves the full 60fps but ES2
>>>>>>> can only manage 30-35fps. It uses lots of overlapping filled
>>>>>>> triangles so I expect suffers from the problem you've
>>>>>>> described.
>>>>>>>
>>>>>>> SSCCE:
>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/j
>>>>>>> ava/ com/ch
>>>>>>>
>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>
>>>>>>> Was full frame rate canvas drawing 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%2
>>>>>>>>>> 0(Op
>>>>>>>>>> en%2C% 20%2 2In%
>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(maco
>>>>>>>>>> sx)% 20%20A
>>>>>>>>>> ND%2
>>>>>>>>>> 0la
>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>
>>>>>>>>>> Given that one of the One of the main reasons to use
>>>>>>>>>> JFX
>>>>>>>>>> for me is to be able to develop with one code base for
>>>>>>>>>> at least OSX and Windows and the official statement what
>>>>>>>>>> JavaFX is for, i.e.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>> deploy rich client applications that operate
>>>>>>>>>> consistently across diverse platforms"
>>>>>>>>>>
>>>>>>>>>> and the fact that this is clearly not the case
>>>>>>>>>> currently (8u40)
>>>>>>>>>> as soon as I do something else than simple forms, I run
>>>>>>>>>> into performance/quality problems on the Mac, I am a bit
>>>>>>>>>> unsure what to make of all that. Is Mac OSX a
>>>>>>>>>> second-class citizen as far as dev resources are
>>>>>>>>>> concerned?
>>>>>>>>>>
>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac
>>>>>>>>>> graphics performance that can be tracked?
>>>>>>>>>>
>>>>>>>>>> I will file an issue with a simple test case and hope
>>>>>>>>>> for the best.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Possibly related:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I can reproduce a massive (90%) performance drop on
>>>>>>>>>>> OSX
>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using
>>>>>>>>>>> a series of gc.strokeLine(double x1, double y1, double
>>>>>>>>>>> x2, double y2) commands versus using a single
>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints,
>>>>>>>>>>> int count) command.
>>>>>>>>>>>
>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>
>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Build with ant
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Run with:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> # use strokeLine
>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7
>>>>>>>>>>> /
>>>>>>>>>>> 20GB RAM
>>>>>>>>>>> /
>>>>>>>>>>> Radeon
>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints,
>>>>>>>>>>> yPoints, nPoints, true, NGCanvas.STROKE_PATH) which
>>>>>>>>>>> involves significantly more work with adding to and
>>>>>>>>>>> flushing a GrowableDataBuffer.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've not had time to dig any deeper than this but
>>>>>>>>>>> it's surely a bug when building a poly manually is 10x
>>>>>>>>>>> faster than using the convenience method.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> In my opinion the whole graphics performance on
>>>>>>>>>>>> MacOSX
>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The bad full screen performance is without the
>>>>>>>>>>>>> arcs. It is
>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and
>>>>>>>>>>>>> one to fillOval, that's all. I will build a simple
>>>>>>>>>>>>> test case and file an issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please file a Jira issue with a simple test
>>>>>>>>>>>>>> case. Arcs
>>>>>>>>>>>>>> are handled as a generalized shape rather than
>>>>>>>>>>>>>> via a predetermined shader, but it shouldn't be
>>>>>>>>>>>>>> that slow. Something else may be going on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>> rectangles or ellipses and see if the
>>>>>>>>>>>>>> performance changes...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a super-simple animation implemented
>>>>>>>>>>>>>>> using AnimationTimer
>>>>>>>>>>>>>>> and Canvas where the canvas just performs a
>>>>>>>>>>>>>>> few draw operations, i.e. fills the screen
>>>>>>>>>>>>>>> with a color and then draws and fills 2-3
>>>>>>>>>>>>>>> circles and I have already observed that each
>>>>>>>>>>>>>>> drawing operation I add, results in
>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10
>>>>>>>>>>>>>>> arcs in addition to the circles, the CPU load
>>>>>>>>>>>>>>> goes up to 30-40% on a Mac Book Pro for a
>>>>>>>>>>>>>>> Canvas size of
>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now I tested the animation in full screen
>>>>>>>>>>>>>>> mode (only
>>>>>>>>>>>>>>> with a few circles) and playback is unusable
>>>>>>>>>>>>>>> for a serious application (very choppy). Is 2D
>>>>>>>>>>>>>>> canvas performance known to be very bad on Mac
>>>>>>>>>>>>>>> or am I doing something wrong? Are there
>>>>>>>>>>>>>>> workarounds for this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Robert Kr??ger
>>>>>>>>>> Managing Partner
>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> www.lesspain-software.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>



From neugens.limasoftware at gmail.com  Thu Apr 16 09:02:19 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 16 Apr 2015 11:02:19 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>
	<CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>
Message-ID: <CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>

As a long time OpenJDK contributor I agree the fact of needing to be
an Author to file bug reports is an inconvenience.

This is something that is discussed basically at every public meeting
where the Governing Board is present (particularly at Fosdem,
sometimes at Java One as well).

For OpenJDK Author is somewhat ok, because the upstream JIRA is mainly
used by people directly working on the code, and since less than
Author (including casual users) can usually file the bug to one of the
downstream OpenJDKs bug databases, like Red Hat/Fedora/Debian
bugzilla, or IcedTea bugzilla, etc... People working on those projects
usually carry on the task to file (and often fix themselves) the bug
upstream, so the kind of filtering that is requested usually is
respected, while still have *some* open door for the general
community.

Less than ideal, but it kind of works...

I realise for OpenJFX this would be more problematic, since there's
not yet a wide downstream community, so the (perhaps limited) benefit
of those external repositories is completely missing in this case.

On the other end, the rules for Author are clear, you need to sign the
OCA (this is the main pain point, but I believe most of the
contributors to OpenJFX already have this done anyway, isn't that a
requirement to use the current JIRA as well?).

Once you're done so, it's up to the projects to decide if a
Contributor can become an Author or not, people that usually
contribute code already (even if they can't push directly) will likely
automagically have the same powers as before.

Right now, to even see an OpenJFX bug I need to log in, so I need an
account. WIth OpenJDK the bugs are accessible so you don't even need
an account to track an issue, here's an example, where I just picked
the first random bug I've seen:

https://bugs.openjdk.java.net/browse/JDK-8075204

I can see that without logging in, something I can't do with the
current bug database, so I don't think the situation is worse really,
it gives more visibility.

Anyway, I encourage you, if you want a better level of access, to
start working with us to find a solution, the right forums is the
"discuss" alias that Dalibor mentioned for a start, and definitely the
Adoption Group can help out in smoothing the transition.

Cheers,
Mario


2015-04-16 9:33 GMT+02:00 Robert Kr?ger <krueger at lesspain.de>:
> On Thursday, April 16, 2015, Ryan Jaeb <ryan at jaeb.ca> wrote:
>
>> My frustration isn't aimed at anyone on the list, so I hope it didn't seem
>> like that.
>>
>> I don't usually post to the list, but I follow it enough to know that, once
>> we see an announcement like the one Kevin delivered, the decision has been
>> made and there's no going back.  If I've misinterpreted, I apologize.
>> Please correct me.
>>
>> The thing that's particularly frustrating with this incident is that it's
>> going to have a predictable, negative impact on people like me who feel
>> like submitting bug reports is the most effect contribution we can make to
>> the JavaFX community.  Being told that we should engage the JBS folks after
>> the decision has been made isn't acceptable.  Whoever made the decision to
>> merge with JBS should already have engaged the JBS folks and advocated for
>> changes on behalf of the JavaFX community before the decision was
>> finalized.  The message Kevin delivered should have included the results of
>> that advocacy.
>>
>> Regardless, what's done is done.  If we need to have someone engage the JBS
>> people to ask for policy changes, I think we'd do well to nominate whoever
>> made the original decision.  If they have enough influence to get a project
>> merged into the JBS, they're effort will be far more effective than that of
>> a random person from the community.
>>
>> We've been told that Oracle wants to see more participation from the JavaFX
>> community.  This is an excellent opportunity for someone with a decision
>> making role at Oracle to take action and demonstrate to the community that
>> they're willing to help facilitate some of that participation.
>>
>>
> Amen to every single aspect you touch. I believe that summarizes pretty
> well how many of us die-hard java desktop/client-side application/product
> developers feel.
>
> @Dalibor: An after-the-fact "Not our responsibility, ask over there" is not
> exactly how you get your community to feel involved. But Ryan has also
> already covered that very well above.



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From krueger at lesspain.de  Thu Apr 16 09:57:10 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 16 Apr 2015 11:57:10 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>
	<CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>
	<CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>
Message-ID: <CAEnqZEXJobX1WJ6K9v-zeDGbR5r0nz9o2wDvuNxVswf8kqALXQ@mail.gmail.com>

On Thu, Apr 16, 2015 at 11:02 AM, Mario Torre <
neugens.limasoftware at gmail.com> wrote:

>
> On the other end, the rules for Author are clear, you need to sign the
> OCA (this is the main pain point, but I believe most of the
> contributors to OpenJFX already have this done anyway, isn't that a
> requirement to use the current JIRA as well?).
>
> No, it isn't. You can just register.
Please note that the main criticism is not that it becomes a problem for
code contributors but for people submitting qualified bug reports including
reproducible test cases, concrete measurements etc. or contribute these
kind of things to issues opened by other people by submitting qualified
comments thus creating value.


> Right now, to even see an OpenJFX bug I need to log in, so I need an
> account. WIth OpenJDK the bugs are accessible so you don't even need
> an account to track an issue, here's an example, where I just picked
> the first random bug I've seen:
>
> https://bugs.openjdk.java.net/browse/JDK-8075204
>
> I can see that without logging in, something I can't do with the
> current bug database, so I don't think the situation is worse really,
> it gives more visibility.
>
>
Yes that is one point that is indeed an improvement and nobody denies that
but it is by far outweighed by the negative consequences of the announced
change and Ryan summarized very precisely why.


> Anyway, I encourage you, if you want a better level of access, to
> start working with us to find a solution, the right forums is the
> "discuss" alias that Dalibor mentioned for a start, and definitely the
> Adoption Group can help out in smoothing the transition.
>

Fair enough but it would still be nice to have someone at Oracle
championing/supporting that in a way on behalf of the JFX community.

From Fabrizio.Giudici at tidalwave.it  Thu Apr 16 10:42:19 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Thu, 16 Apr 2015 12:42:19 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEnqZEXJobX1WJ6K9v-zeDGbR5r0nz9o2wDvuNxVswf8kqALXQ@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>
	<CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>
	<CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>
	<CAEnqZEXJobX1WJ6K9v-zeDGbR5r0nz9o2wDvuNxVswf8kqALXQ@mail.gmail.com>
Message-ID: <op.xw6k7fxu2ilaq7@localhost>

On Thu, 16 Apr 2015 11:57:10 +0200, Robert Kr?ger <krueger at lesspain.de>  
wrote:

> Please note that the main criticism is not that it becomes a problem for
> code contributors but for people submitting qualified bug reports  
> including
> reproducible test cases, concrete measurements etc. or contribute these
> kind of things to issues opened by other people by submitting qualified
> comments thus creating value.

Exactly. Resuming my previous points, one of the most valuables sources of  
bug tracking (when a quality filter has been applied) are developers who  
strategically use the technology evesomewhere. When talking of general  
FLOSS (or even non FLOSS, but with public issue tracking) I constantly  
push people to be active and file issues by themselves (I sometimes  
support them on how to prepare a good report, hoping that after a  
bootstrap they become independent). Any obstacle in this path ends up in  
people working around bugs. Which is a pity, because this means that many  
bugs aren't fixed, people waste efforts in duplicating workarounds (*) and  
in the long run the technology might take a reputation of being  
problematic to use.

(*) That's why commenting is important. It's quite frequent that when I  
find a problem with a technology and google around I end up to an issue  
tracker and find some people who at least was able to provide an effective  
workaround that, even though not perfectly, make me able to avoid a  
blocking point, waiting for an issue to be corrected. This job could be  
eventually dealt with a properly indexed forum.

Adding points to the brainstorming section... what about a public,  
separate issue tracker to leave in the wild? Perhaps not officially  
maintained by Oracle, to avoid any criticism. The idea is that in this  
public, restrictionless Jira it's up to the community to apply the proper  
policy to keep noise low. From this public instance, selected issues  
complying with some well defined requirements could be later moved to the  
official Jira.

This would require some involvement by the community (I mean, more than  
just describing bugs and providing patches: it would have a role in  
moderating the public instance, and I understand this is definitely much  
more boring than grokking code), but I think this is somewhat unavoidable  
if Oracle doesn' want to pay the costs for this activity.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From kevin.rushforth at oracle.com  Thu Apr 16 12:01:03 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 16 Apr 2015 05:01:03 -0700
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
References: <552D92B8.4030509@oracle.com>	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>	<op.xw4mkuxy2ilaq7@wdtvlivehub>	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
Message-ID: <552FA47F.8060100@oracle.com>

Exactly. This is an OpenJDK policy issue. Dalibor posted the link to the 
discuss alias that you might send an e-mail to.

-- Kevin


Richard Bair wrote:
>> Why can't an effort be made to influence JBS policies before making the switch?
>>     
>
> I think the way to do this is to engage the JBS folks on their alias, I don?t think they watch this one and Kevin doesn?t have the ability to change this policy. He?s just the messenger!
>
> Richard

From Fabrizio.Giudici at tidalwave.it  Thu Apr 16 12:35:39 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Thu, 16 Apr 2015 14:35:39 +0200
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552FA47F.8060100@oracle.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<552FA47F.8060100@oracle.com>
Message-ID: <op.xw6qlp1c2ilaq7@localhost>

On Thu, 16 Apr 2015 14:01:03 +0200, Kevin Rushforth  
<kevin.rushforth at oracle.com> wrote:

> Exactly. This is an OpenJDK policy issue. Dalibor posted the link to the  
> discuss alias that you might send an e-mail to.

So, ok, this specific discussion should move there. I subscribed to the ml  
pointed by Dalibor, all the one involved please do the same, and then  
let's start there.


-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From kevin.rushforth at oracle.com  Thu Apr 16 12:47:33 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 16 Apr 2015 05:47:33 -0700
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>	<op.xw4mkuxy2ilaq7@wdtvlivehub>	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>	<CAOrfuJ0=1NvLNndmMvM1WGiV-iV1WaA9qxNGPjQA3d96uMUbTQ@mail.gmail.com>	<CAEnqZEXVShQ6n-aNUWtTkjsLQEa6izBgtxZzQxRV3rrs5mfcEQ@mail.gmail.com>
	<CAGUMyaRr7toRxOY65HfQniCuj07dbF3unG9GQGbFUHCp9Yc4+w@mail.gmail.com>
Message-ID: <552FAF65.80702@oracle.com>

I was talking to Phil about a related point yesterday. One thing we (the 
JavaFX developers at Oracle) will need to do is to take a more active 
approach in helping bugs filed at bugs.java.com make their way from the 
internal "Incidents" project into the JDK project as an active bug. This 
doesn't address the concerns over not being able to comment on bugs, but 
will I hope provide a somewhat better path for app developers to file 
bugs (at least until the bugs.java.com portal is improved).

-- Kevin


Mario Torre wrote:
> As a long time OpenJDK contributor I agree the fact of needing to be
> an Author to file bug reports is an inconvenience.
>
> This is something that is discussed basically at every public meeting
> where the Governing Board is present (particularly at Fosdem,
> sometimes at Java One as well).
>
> For OpenJDK Author is somewhat ok, because the upstream JIRA is mainly
> used by people directly working on the code, and since less than
> Author (including casual users) can usually file the bug to one of the
> downstream OpenJDKs bug databases, like Red Hat/Fedora/Debian
> bugzilla, or IcedTea bugzilla, etc... People working on those projects
> usually carry on the task to file (and often fix themselves) the bug
> upstream, so the kind of filtering that is requested usually is
> respected, while still have *some* open door for the general
> community.
>
> Less than ideal, but it kind of works...
>
> I realise for OpenJFX this would be more problematic, since there's
> not yet a wide downstream community, so the (perhaps limited) benefit
> of those external repositories is completely missing in this case.
>
> On the other end, the rules for Author are clear, you need to sign the
> OCA (this is the main pain point, but I believe most of the
> contributors to OpenJFX already have this done anyway, isn't that a
> requirement to use the current JIRA as well?).
>
> Once you're done so, it's up to the projects to decide if a
> Contributor can become an Author or not, people that usually
> contribute code already (even if they can't push directly) will likely
> automagically have the same powers as before.
>
> Right now, to even see an OpenJFX bug I need to log in, so I need an
> account. WIth OpenJDK the bugs are accessible so you don't even need
> an account to track an issue, here's an example, where I just picked
> the first random bug I've seen:
>
> https://bugs.openjdk.java.net/browse/JDK-8075204
>
> I can see that without logging in, something I can't do with the
> current bug database, so I don't think the situation is worse really,
> it gives more visibility.
>
> Anyway, I encourage you, if you want a better level of access, to
> start working with us to find a solution, the right forums is the
> "discuss" alias that Dalibor mentioned for a start, and definitely the
> Adoption Group can help out in smoothing the transition.
>
> Cheers,
> Mario
>
>
> 2015-04-16 9:33 GMT+02:00 Robert Kr?ger <krueger at lesspain.de>:
>   
>> On Thursday, April 16, 2015, Ryan Jaeb <ryan at jaeb.ca> wrote:
>>
>>     
>>> My frustration isn't aimed at anyone on the list, so I hope it didn't seem
>>> like that.
>>>
>>> I don't usually post to the list, but I follow it enough to know that, once
>>> we see an announcement like the one Kevin delivered, the decision has been
>>> made and there's no going back.  If I've misinterpreted, I apologize.
>>> Please correct me.
>>>
>>> The thing that's particularly frustrating with this incident is that it's
>>> going to have a predictable, negative impact on people like me who feel
>>> like submitting bug reports is the most effect contribution we can make to
>>> the JavaFX community.  Being told that we should engage the JBS folks after
>>> the decision has been made isn't acceptable.  Whoever made the decision to
>>> merge with JBS should already have engaged the JBS folks and advocated for
>>> changes on behalf of the JavaFX community before the decision was
>>> finalized.  The message Kevin delivered should have included the results of
>>> that advocacy.
>>>
>>> Regardless, what's done is done.  If we need to have someone engage the JBS
>>> people to ask for policy changes, I think we'd do well to nominate whoever
>>> made the original decision.  If they have enough influence to get a project
>>> merged into the JBS, they're effort will be far more effective than that of
>>> a random person from the community.
>>>
>>> We've been told that Oracle wants to see more participation from the JavaFX
>>> community.  This is an excellent opportunity for someone with a decision
>>> making role at Oracle to take action and demonstrate to the community that
>>> they're willing to help facilitate some of that participation.
>>>
>>>
>>>       
>> Amen to every single aspect you touch. I believe that summarizes pretty
>> well how many of us die-hard java desktop/client-side application/product
>> developers feel.
>>
>> @Dalibor: An after-the-fact "Not our responsibility, ask over there" is not
>> exactly how you get your community to feel involved. But Ryan has also
>> already covered that very well above.
>>     
>
>
>
>   

From ryan at jaeb.ca  Thu Apr 16 12:50:08 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Thu, 16 Apr 2015 06:50:08 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <op.xw6qlp1c2ilaq7@localhost>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
	<CAOrfuJ2j2ZR8HQN8UEhgTsHkB3w7ujvUFCOJDyqOrjWrHvTz=w@mail.gmail.com>
	<F18DE72F-E394-46C2-9DF0-2A49C8169C50@oracle.com>
	<552FA47F.8060100@oracle.com> <op.xw6qlp1c2ilaq7@localhost>
Message-ID: <CAOrfuJ2dC37SRFWmcHCzBB58-TyLrWcH-m17shj3e1Sb7Dhcuw@mail.gmail.com>

I started a  thread over there just before I saw these last couple replies.

http://mail.openjdk.java.net/pipermail/discuss/2015-April/003719.html

Ryan Jaeb

On Thu, Apr 16, 2015 at 6:35 AM, Fabrizio Giudici <
Fabrizio.Giudici at tidalwave.it> wrote:

> On Thu, 16 Apr 2015 14:01:03 +0200, Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>  Exactly. This is an OpenJDK policy issue. Dalibor posted the link to the
>> discuss alias that you might send an e-mail to.
>>
>
> So, ok, this specific discussion should move there. I subscribed to the ml
> pointed by Dalibor, all the one involved please do the same, and then let's
> start there.
>
>
> --
> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
> "We make Java work. Everywhere."
> http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it
>

From kevin.rushforth at oracle.com  Thu Apr 16 12:50:16 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 16 Apr 2015 05:50:16 -0700
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <CAEQxcvGMNiArPPXWEhQ6veKBAngL2sLeyvhK00RALF7qxfkdCA@mail.gmail.com>
References: <552D92B8.4030509@oracle.com>
	<CAEQxcvGMNiArPPXWEhQ6veKBAngL2sLeyvhK00RALF7qxfkdCA@mail.gmail.com>
Message-ID: <552FB008.9050405@oracle.com>

Not in this initial phase, mainly due to the tight schedule and amount 
of work involved, but likely in a follow-up phase.

-- Kevin


Anirvan Sarkar wrote:
> On 15 April 2015 at 03:50, Kevin Rushforth <kevin.rushforth at oracle.com 
> <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     ...
>     The issues currently in the RT project in JavaFX JIRA will be
>     folded into the JDK project in JBS.
>
>
> What about the Scene Builder issues (DTL project in JavaFX JIRA)? 
> Would they also be migrated to JBS?
>
> -- 
> Anirvan

From ddudouit at clio.ch  Thu Apr 16 13:52:34 2015
From: ddudouit at clio.ch (Damien Dudouit)
Date: Thu, 16 Apr 2015 15:52:34 +0200
Subject: Font size
Message-ID: <CAAJRru0m1JQxv+StYihb2UcF=XnsS3WoPGz7qjMvrLVkUW11Kg@mail.gmail.com>

Hello,

I'm experimenting with Java FX on a Windows 7 machine, using Java 1.8.0_40.

The Font javadoc says :




import javafx.scene.control.TextArea;
import javafx.scene.text.Font;
import javafx.scene.text.FontPosture;

TextArea editor = new TextArea();
editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));

From ddudouit at clio.ch  Thu Apr 16 14:28:15 2015
From: ddudouit at clio.ch (Damien Dudouit)
Date: Thu, 16 Apr 2015 16:28:15 +0200
Subject: Font size, dpi and text crispness (snapping to pixels)
Message-ID: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>

Hello,

I'm experimenting with Java FX on a Windows 7 machine, using Java 1.8.0_40.

The *javafx.scene.text.*Font javadoc says :

*The size of a Font is described as being specified in points which are a
real world measurement of approximately 1/72 inch. *

*[...] Note that the real world distances specified by the default
coordinate system only approximate point sizes as a rule of thumb and are
typically defaulted to screen pixels for most displays. *

Java FX behaves as if the display dpi is 72 while in my case for instance
its about 96. 96/72 = 1.3333.

So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10) as
a font on a javafx.scene.control.TextArea, text appears a lot smaller than
in my eclipse editor configured with the same font.
Obviously, I get about the same visual size if I use a font size of 13 in
Java FX while using the same font in size 10 in Eclipse.

I guess I could set scaling somehow in my Java FX code. But using scaling,
I imagine that text has little chance to display as crisp as it should.

In fact, trying to compare the pixel output of Eclipse with font size 10
and Java FX in font size 13 (or 13.333), the Java FX one is slightly blurry.

What can be done in Java FX when an application needs text as clear as
possible, for instance if the application is a text editor ?

What is the correct approach in a Java FX app so that it respect the
default font size configured at the OS level ?


Thanks a lot in advance,

Damien


public final class MyApplication extends Application {

  public static void main(String[] args) {
    launch(args);
  }

  @Override
  public void start(Stage primaryStage) {
    TextArea editor = new TextArea();

    editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));

    primaryStage.setScene(new Scene(editor));
    primaryStage.show();

    System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
  }
}

From philip.race at oracle.com  Thu Apr 16 15:46:01 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 Apr 2015 08:46:01 -0700
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
References: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
Message-ID: <552FD939.9050203@oracle.com>


https://docs.oracle.com/javase/8/javafx/api/javafx/scene/text/Font.html#getDefault--

Gets the default font which will be from the family "System", and 
typically the style "Regular",
and be of a size consistent with the user's desktop environment, to the 
extent that can be determined.


-phil.

On 04/16/2015 07:28 AM, Damien Dudouit wrote:
> Hello,
>
> I'm experimenting with Java FX on a Windows 7 machine, using Java 1.8.0_40.
>
> The *javafx.scene.text.*Font javadoc says :
>
> *The size of a Font is described as being specified in points which are a
> real world measurement of approximately 1/72 inch. *
>
> *[...] Note that the real world distances specified by the default
> coordinate system only approximate point sizes as a rule of thumb and are
> typically defaulted to screen pixels for most displays. *
>
> Java FX behaves as if the display dpi is 72 while in my case for instance
> its about 96. 96/72 = 1.3333.
>
> So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10) as
> a font on a javafx.scene.control.TextArea, text appears a lot smaller than
> in my eclipse editor configured with the same font.
> Obviously, I get about the same visual size if I use a font size of 13 in
> Java FX while using the same font in size 10 in Eclipse.
>
> I guess I could set scaling somehow in my Java FX code. But using scaling,
> I imagine that text has little chance to display as crisp as it should.
>
> In fact, trying to compare the pixel output of Eclipse with font size 10
> and Java FX in font size 13 (or 13.333), the Java FX one is slightly blurry.
>
> What can be done in Java FX when an application needs text as clear as
> possible, for instance if the application is a text editor ?
>
> What is the correct approach in a Java FX app so that it respect the
> default font size configured at the OS level ?
>
>
> Thanks a lot in advance,
>
> Damien
>
>
> public final class MyApplication extends Application {
>
>    public static void main(String[] args) {
>      launch(args);
>    }
>
>    @Override
>    public void start(Stage primaryStage) {
>      TextArea editor = new TextArea();
>
>      editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));
>
>      primaryStage.setScene(new Scene(editor));
>      primaryStage.show();
>
>      System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
>    }
> }


From alexander.zvegintsev at oracle.com  Thu Apr 16 16:59:31 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 16 Apr 2015 19:59:31 +0300
Subject: [8u60,
	9] Review request for  RT-40548: [GTK] Gdk-ERROR **: g_thread_init()
	must be called before gdk_threads_init()
Message-ID: <552FEA73.5040600@oracle.com>

Hello,

please review the fix
http://cr.openjdk.java.net/~azvegint/fx/8u60/40548/00/
for the issue
https://javafx-jira.kenai.com/browse/RT-40548

-- 
Thanks,

Alexander.


From jeff at reportmill.com  Thu Apr 16 17:12:15 2015
From: jeff at reportmill.com (Jeff Martin)
Date: Thu, 16 Apr 2015 12:12:15 -0500
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
References: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
Message-ID: <220D6C95-1D6D-4A88-AF11-F93D5AEB4343@reportmill.com>

I?m surprised about the font size problem - If I create a font with new Font(?Monaco?, 10), text shows up the same size as it does in Eclipse.

I don?t think there is a solution for the blurry problem, however, because there is no way to disable Antialiasing. In Swing, I was able to get crisp rendering identical to eclipse by checking for very specific fonts/sizes and disabling TEXT_ANTIALIASING.

The only solution in JavaFX may be to get a Retina monitor. This didn?t seem to be a terrible proposition to me last year, when it seemed like almost everything from phones to tablets to laptops had gone HiDPI. It?s taking forever for the desktop world to catch on, though. Apple is taking it?s time. Dell apparently has a nice 5k external, but it needs two mini display ports to drive it.

jeff


On Apr 16, 2015, at 9:28 AM, Damien Dudouit <ddudouit at clio.ch> wrote:

> Hello,
> 
> I'm experimenting with Java FX on a Windows 7 machine, using Java 1.8.0_40.
> 
> The *javafx.scene.text.*Font javadoc says :
> 
> *The size of a Font is described as being specified in points which are a
> real world measurement of approximately 1/72 inch. *
> 
> *[...] Note that the real world distances specified by the default
> coordinate system only approximate point sizes as a rule of thumb and are
> typically defaulted to screen pixels for most displays. *
> 
> Java FX behaves as if the display dpi is 72 while in my case for instance
> its about 96. 96/72 = 1.3333.
> 
> So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10) as
> a font on a javafx.scene.control.TextArea, text appears a lot smaller than
> in my eclipse editor configured with the same font.
> Obviously, I get about the same visual size if I use a font size of 13 in
> Java FX while using the same font in size 10 in Eclipse.
> 
> I guess I could set scaling somehow in my Java FX code. But using scaling,
> I imagine that text has little chance to display as crisp as it should.
> 
> In fact, trying to compare the pixel output of Eclipse with font size 10
> and Java FX in font size 13 (or 13.333), the Java FX one is slightly blurry.
> 
> What can be done in Java FX when an application needs text as clear as
> possible, for instance if the application is a text editor ?
> 
> What is the correct approach in a Java FX app so that it respect the
> default font size configured at the OS level ?
> 
> 
> Thanks a lot in advance,
> 
> Damien
> 
> 
> public final class MyApplication extends Application {
> 
>  public static void main(String[] args) {
>    launch(args);
>  }
> 
>  @Override
>  public void start(Stage primaryStage) {
>    TextArea editor = new TextArea();
> 
>    editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));
> 
>    primaryStage.setScene(new Scene(editor));
>    primaryStage.show();
> 
>    System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
>  }
> }


From tomas.mikula at gmail.com  Thu Apr 16 18:06:30 2015
From: tomas.mikula at gmail.com (Tomas Mikula)
Date: Thu, 16 Apr 2015 14:06:30 -0400
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
References: <552D92B8.4030509@oracle.com>
	<CAOrfuJ1_uFtKUO-sbAyY9YK_uhO_fH78gN92LD3eZq+X01+5Kw@mail.gmail.com>
	<CAEnqZEUVJ4=vOdJ5OajBWUHwjY=c3SXP7Hy7Poa_DEhVr0+GsA@mail.gmail.com>
	<op.xw4mkuxy2ilaq7@wdtvlivehub>
	<ACFBE6EF-7798-4560-832E-5B46F8B347FB@oracle.com>
Message-ID: <CA+THrurjrMUTkakhr2UVLVd_3xgP63Onhp9Wvb5fFeZ3zd0+jg@mail.gmail.com>

On Wed, Apr 15, 2015 at 10:54 AM, Richard Bair <richard.bair at oracle.com> wrote:
> This is exactly the issue. We know from the last 20 years that in fact we get a huge amount of completely bogus bugs that get filed via bugs.java.com <http://bugs.java.com/> (previously bugs.sun.com <http://bugs.sun.com/>). Wild stuff from end users like ?I can?t reboot my computer? and so forth. The concern with JBS (as I understand it) was that we?d end up with 10?s or 100,000?s of thousands of user accounts, many of which would be one-shot submitters associated with bogus issues.

This is a problem of a huge community, but also can be solved by the
community: if community members can flag those bug reports and a
consensus of, say, 5 community members is sufficient to close the
issue. Just like on StackOverflow.

Tomas

From johan at lodgon.com  Thu Apr 16 19:58:28 2015
From: johan at lodgon.com (Johan Vos)
Date: Thu, 16 Apr 2015 21:58:28 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <552D67A3.7060004@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
Message-ID: <CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>

Hi Jim,

On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
Excellent work!

- Johan

2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:

> Hi Chris,
>
> We identified a fairly localized optimization that we might be able to
> apply to enhance the performance of your Sierpinski program.  We don't have
> any figures yet on whether this will improve other applications/benchmarks
> that people have been discussing, but the improvements with your Sierpinski
> program are quite dramatic on a number of platforms and GPUs.
>
> This issue is now being tracked as: https://javafx-jira.kenai.com/
> browse/RT-40533
>
> If others could apply the indicated patch to an OpenJFX build and provide
> feedback on any improvements (or bugs!) that they see, that would help.  In
> the meantime, we have a lot of testing to do to verify the correctness of
> the changes...
>
>                         ...jim
>
>
> On 4/8/15 9:25 AM, Chris Newland wrote:
>
>> Hi Jim,
>>
>> I'll post the verbose prism output from my iMac when I get home.
>>
>> Just tried this on my Linux workstation and the performance gap is the
>> same between es2 and sw so I don't think it's an OSX issue.
>>
>> uname -a
>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>>
>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>> com.chrisnewland.demofx.standalone.Sierpinski
>> fps: 1
>> fps: 20
>> fps: 31
>> fps: 32
>> fps: 33
>> fps: 35
>> fps: 34
>> fps: 33
>>
>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>> com.chrisnewland.demofx.standalone.Sierpinski
>> fps: 1
>> fps: 54
>> fps: 56
>> fps: 60
>> fps: 59
>> fps: 60
>> fps: 61
>> fps: 61
>> fps: 60
>>
>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>> graphics card running driver 304.125
>>
>> Regards,
>>
>> Chris
>>
>>
>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>
>>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
>>> 10.10,
>>> so my theory that something changed in the OGL implementation for 10.10
>>> doesn't hold water.
>>>
>>> But, I then tried it using the integrated graphics.  I get really poor
>>> performance using the integrated Intel 4000 graphics, but I get great
>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>> shouldn't be taxing it that much to make that big of a difference.
>>>
>>> Just to be sure - is that iMac a dual graphics system, or is it
>>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>>> with -Dprism.verbose=true...
>>>
>>> ...jim
>>>
>>>
>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>
>>>  On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>>> running a newer version of MacOS?
>>>>
>>>> ...jim
>>>>
>>>>
>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>
>>>>  Hi Herv?,
>>>>>
>>>>>
>>>>> That's a valid question :)
>>>>>
>>>>>
>>>>> Probably because
>>>>>
>>>>>
>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>>> systems
>>>>>
>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>>> to go for that due to the very large number of nodes.
>>>>>
>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>
>>>>>
>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>> 1024 MB
>>>>>
>>>>>
>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>> fps: 23
>>>>> fps: 18
>>>>> fps: 25
>>>>> fps: 18
>>>>> fps: 23
>>>>> fps: 23
>>>>> fps: 19
>>>>> fps: 25
>>>>>
>>>>>
>>>>> java -Dprism.order=sw -cp target/classes/
>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>> fps: 54
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>> fps: 60
>>>>>
>>>>>
>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>> 1.8.0_40
>>>>>
>>>>>
>>>>> I would say there is a performance problem here? (or at least a need
>>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>
>>>>>  Why don't you use Nodes rather than Canvas ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>> <cnewland at chrisnewland.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks, that makes things much clearer.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I was surprised how much was going on under the hood of
>>>>>>> GraphicsContext
>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>> rasterizing where not.
>>>>>>>
>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>>> so I expect suffers from the problem you've described.
>>>>>>>
>>>>>>> SSCCE:
>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>>> com/ch
>>>>>>>
>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>
>>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>>> JavaFX or
>>>>>>> would I be better off with Graphics2D?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>>> with a GPU
>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>>> with an appropriate shader which is very fast.
>>>>>>>>
>>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>>> like:
>>>>>>>>
>>>>>>>>
>>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>>   drawLine() - dealing with only rendering common points of
>>>>>>>> intersection once
>>>>>>>>
>>>>>>>> To handle all of that complexity we have to involve a
>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>>> currently for all pipelines.
>>>>>>>>
>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>>> CPU path
>>>>>>>> rasterization.
>>>>>>>>
>>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>>> dominates its performance.
>>>>>>>>
>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>>
>>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>>> case. Does
>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>>> SW
>>>>>>>> pipeline for the polygon case?
>>>>>>>>
>>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>>> calls faster than drawPolygon as well...
>>>>>>>>
>>>>>>>> ...jim
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Robert,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>>> I'd
>>>>>>>>> better add my findings.
>>>>>>>>>
>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>>> strokeLine commands as expected:
>>>>>>>>>
>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>>> Result:
>>>>>>>>> 44fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>>> Result:
>>>>>>>>> 60fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>>   examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>>
>>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>>> JavaFX
>>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>>> do think there's a bug here.
>>>>>>>>>
>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>>> slow" ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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(Op
>>>>>>>>>> en%2C% 20%2
>>>>>>>>>> 2In%
>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>>> 20%20A
>>>>>>>>>> ND%2
>>>>>>>>>> 0la
>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>
>>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>>> least OSX and Windows and
>>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>>
>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>>> across diverse platforms"
>>>>>>>>>>
>>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>>> (8u40)
>>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>>   performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>>
>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>>> performance that can be tracked?
>>>>>>>>>>
>>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>>> the best.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Possibly related:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>>> count) command.
>>>>>>>>>>>
>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>
>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Build with ant
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Run with:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> # use strokeLine
>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>>> 20GB RAM
>>>>>>>>>>> /
>>>>>>>>>>> Radeon
>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>>> than using the convenience method.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>>> It is
>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Hi Robert,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>>   predetermined shader, but it shouldn't be that
>>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>>   AnimationTimer
>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>>   serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Robert Kr??ger
>>>>>>>>>> Managing Partner
>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>

From kevin.rushforth at oracle.com  Thu Apr 16 20:02:37 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 16 Apr 2015 13:02:37 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>	<5515C483.9030901@oracle.com>	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>	<55199E52.9090503@oracle.com>	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>	<551DCD2F.8080900@oracle.com>
	<5524654C.2060500@oracle.com>	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>	<552D67A3.7060004@oracle.com>
	<CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
Message-ID: <5530155D.70607@oracle.com>

Excellent!

-- Kevin


Johan Vos wrote:
> Hi Jim,
>
> On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
> Excellent work!
>
> - Johan
>
> 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>
>   
>> Hi Chris,
>>
>> We identified a fairly localized optimization that we might be able to
>> apply to enhance the performance of your Sierpinski program.  We don't have
>> any figures yet on whether this will improve other applications/benchmarks
>> that people have been discussing, but the improvements with your Sierpinski
>> program are quite dramatic on a number of platforms and GPUs.
>>
>> This issue is now being tracked as: https://javafx-jira.kenai.com/
>> browse/RT-40533
>>
>> If others could apply the indicated patch to an OpenJFX build and provide
>> feedback on any improvements (or bugs!) that they see, that would help.  In
>> the meantime, we have a lot of testing to do to verify the correctness of
>> the changes...
>>
>>                         ...jim
>>
>>
>> On 4/8/15 9:25 AM, Chris Newland wrote:
>>
>>     
>>> Hi Jim,
>>>
>>> I'll post the verbose prism output from my iMac when I get home.
>>>
>>> Just tried this on my Linux workstation and the performance gap is the
>>> same between es2 and sw so I don't think it's an OSX issue.
>>>
>>> uname -a
>>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>>>
>>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 20
>>> fps: 31
>>> fps: 32
>>> fps: 33
>>> fps: 35
>>> fps: 34
>>> fps: 33
>>>
>>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 54
>>> fps: 56
>>> fps: 60
>>> fps: 59
>>> fps: 60
>>> fps: 61
>>> fps: 61
>>> fps: 60
>>>
>>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>>> graphics card running driver 304.125
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
>>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>>
>>>       
>>>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
>>>> 10.10,
>>>> so my theory that something changed in the OGL implementation for 10.10
>>>> doesn't hold water.
>>>>
>>>> But, I then tried it using the integrated graphics.  I get really poor
>>>> performance using the integrated Intel 4000 graphics, but I get great
>>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>>> shouldn't be taxing it that much to make that big of a difference.
>>>>
>>>> Just to be sure - is that iMac a dual graphics system, or is it
>>>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>>>> with -Dprism.verbose=true...
>>>>
>>>> ...jim
>>>>
>>>>
>>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>>
>>>>  On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>>>         
>>>>> running a newer version of MacOS?
>>>>>
>>>>> ...jim
>>>>>
>>>>>
>>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>>
>>>>>  Hi Herv?,
>>>>>           
>>>>>> That's a valid question :)
>>>>>>
>>>>>>
>>>>>> Probably because
>>>>>>
>>>>>>
>>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>>>> systems
>>>>>>
>>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>>>> to go for that due to the very large number of nodes.
>>>>>>
>>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>>
>>>>>>
>>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>>> 1024 MB
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 23
>>>>>> fps: 18
>>>>>> fps: 25
>>>>>> fps: 18
>>>>>> fps: 23
>>>>>> fps: 23
>>>>>> fps: 19
>>>>>> fps: 25
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=sw -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 54
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>>
>>>>>>
>>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>>> 1.8.0_40
>>>>>>
>>>>>>
>>>>>> I would say there is a performance problem here? (or at least a need
>>>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>>
>>>>>>  Why don't you use Nodes rather than Canvas ?
>>>>>>             
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>>               
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks, that makes things much clearer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was surprised how much was going on under the hood of
>>>>>>>> GraphicsContext
>>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>>> rasterizing where not.
>>>>>>>>
>>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>>>> so I expect suffers from the problem you've described.
>>>>>>>>
>>>>>>>> SSCCE:
>>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>>>> com/ch
>>>>>>>>
>>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>>
>>>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>>>> JavaFX or
>>>>>>>> would I be better off with Graphics2D?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>>>                 
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>>>> with a GPU
>>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>>>> with an appropriate shader which is very fast.
>>>>>>>>>
>>>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>>>> like:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>>>   drawLine() - dealing with only rendering common points of
>>>>>>>>> intersection once
>>>>>>>>>
>>>>>>>>> To handle all of that complexity we have to involve a
>>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>>>> currently for all pipelines.
>>>>>>>>>
>>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>>>> CPU path
>>>>>>>>> rasterization.
>>>>>>>>>
>>>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>>>> dominates its performance.
>>>>>>>>>
>>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>>>
>>>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>>>> case. Does
>>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>>>> SW
>>>>>>>>> pipeline for the polygon case?
>>>>>>>>>
>>>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>>>> calls faster than drawPolygon as well...
>>>>>>>>>
>>>>>>>>> ...jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>>                   
>>>>>>>>>>
>>>>>>>>>> Hi Robert,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>>>> I'd
>>>>>>>>>> better add my findings.
>>>>>>>>>>
>>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>>>> strokeLine commands as expected:
>>>>>>>>>>
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>>>> Result:
>>>>>>>>>> 44fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>>>> Result:
>>>>>>>>>> 60fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>>>   examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>>>
>>>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>>>> JavaFX
>>>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>>>> do think there's a bug here.
>>>>>>>>>>
>>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>>>> slow" ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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(Op
>>>>>>>>>>> en%2C% 20%2
>>>>>>>>>>> 2In%
>>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>>>> 20%20A
>>>>>>>>>>> ND%2
>>>>>>>>>>> 0la
>>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>>
>>>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>>>> least OSX and Windows and
>>>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>>>
>>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>>>> across diverse platforms"
>>>>>>>>>>>
>>>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>>>> (8u40)
>>>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>>>   performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>>>
>>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>>>> performance that can be tracked?
>>>>>>>>>>>
>>>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>>>> the best.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Possibly related:
>>>>>>>>>>>                       
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>>>> count) command.
>>>>>>>>>>>>
>>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>>
>>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Build with ant
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Run with:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokeLine
>>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>>>> 20GB RAM
>>>>>>>>>>>> /
>>>>>>>>>>>> Radeon
>>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>>>> than using the convenience method.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>>>                         
>>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Hi Robert,
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>>>   predetermined shader, but it shouldn't be that
>>>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>>>                               
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>>>   AnimationTimer
>>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>>>   serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                             
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr??ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>
>>>>>>>>>>>                       
>>>>>>>>                 
>>>>>>             
>>>       

From tobi at ultramixer.com  Thu Apr 16 20:05:30 2015
From: tobi at ultramixer.com (Tobias Bley)
Date: Thu, 16 Apr 2015 22:05:30 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
	<CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
Message-ID: <0500EFE7-DC46-4A46-A37E-204AF87FD9DD@ultramixer.com>

Hi Johan,

I would like to test it on iPad 1 and iPhone 4, would it be possible now via JavaFXPorts-Gradle-Plugin?

Best,
Tobi


> Am 16.04.2015 um 21:58 schrieb Johan Vos <johan at lodgon.com>:
> 
> Hi Jim,
> 
> On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
> Excellent work!
> 
> - Johan
> 
> 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
> 
>> Hi Chris,
>> 
>> We identified a fairly localized optimization that we might be able to
>> apply to enhance the performance of your Sierpinski program.  We don't have
>> any figures yet on whether this will improve other applications/benchmarks
>> that people have been discussing, but the improvements with your Sierpinski
>> program are quite dramatic on a number of platforms and GPUs.
>> 
>> This issue is now being tracked as: https://javafx-jira.kenai.com/
>> browse/RT-40533
>> 
>> If others could apply the indicated patch to an OpenJFX build and provide
>> feedback on any improvements (or bugs!) that they see, that would help.  In
>> the meantime, we have a lot of testing to do to verify the correctness of
>> the changes...
>> 
>>                        ...jim
>> 
>> 
>> On 4/8/15 9:25 AM, Chris Newland wrote:
>> 
>>> Hi Jim,
>>> 
>>> I'll post the verbose prism output from my iMac when I get home.
>>> 
>>> Just tried this on my Linux workstation and the performance gap is the
>>> same between es2 and sw so I don't think it's an OSX issue.
>>> 
>>> uname -a
>>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>>> 
>>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 20
>>> fps: 31
>>> fps: 32
>>> fps: 33
>>> fps: 35
>>> fps: 34
>>> fps: 33
>>> 
>>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 54
>>> fps: 56
>>> fps: 60
>>> fps: 59
>>> fps: 60
>>> fps: 61
>>> fps: 61
>>> fps: 60
>>> 
>>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>>> graphics card running driver 304.125
>>> 
>>> Regards,
>>> 
>>> Chris
>>> 
>>> 
>>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>> 
>>>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
>>>> 10.10,
>>>> so my theory that something changed in the OGL implementation for 10.10
>>>> doesn't hold water.
>>>> 
>>>> But, I then tried it using the integrated graphics.  I get really poor
>>>> performance using the integrated Intel 4000 graphics, but I get great
>>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>>> shouldn't be taxing it that much to make that big of a difference.
>>>> 
>>>> Just to be sure - is that iMac a dual graphics system, or is it
>>>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>>>> with -Dprism.verbose=true...
>>>> 
>>>> ...jim
>>>> 
>>>> 
>>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>> 
>>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>>>> running a newer version of MacOS?
>>>>> 
>>>>> ...jim
>>>>> 
>>>>> 
>>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>> 
>>>>> Hi Herv?,
>>>>>> 
>>>>>> 
>>>>>> That's a valid question :)
>>>>>> 
>>>>>> 
>>>>>> Probably because
>>>>>> 
>>>>>> 
>>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>>>> systems
>>>>>> 
>>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>>>> to go for that due to the very large number of nodes.
>>>>>> 
>>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>> 
>>>>>> 
>>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>>> 1024 MB
>>>>>> 
>>>>>> 
>>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 23
>>>>>> fps: 18
>>>>>> fps: 25
>>>>>> fps: 18
>>>>>> fps: 23
>>>>>> fps: 23
>>>>>> fps: 19
>>>>>> fps: 25
>>>>>> 
>>>>>> 
>>>>>> java -Dprism.order=sw -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 54
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> 
>>>>>> 
>>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>>> 1.8.0_40
>>>>>> 
>>>>>> 
>>>>>> I would say there is a performance problem here? (or at least a need
>>>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> 
>>>>>> Chris
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>> 
>>>>>> Why don't you use Nodes rather than Canvas ?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Jim,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks, that makes things much clearer.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I was surprised how much was going on under the hood of
>>>>>>>> GraphicsContext
>>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>>> rasterizing where not.
>>>>>>>> 
>>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>>>> so I expect suffers from the problem you've described.
>>>>>>>> 
>>>>>>>> SSCCE:
>>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>>>> com/ch
>>>>>>>> 
>>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>> 
>>>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>>>> JavaFX or
>>>>>>>> would I be better off with Graphics2D?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Chris
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>>>> Hi Chris,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>>>> with a GPU
>>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>>>> with an appropriate shader which is very fast.
>>>>>>>>> 
>>>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>>>> like:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>>>  drawLine() - dealing with only rendering common points of
>>>>>>>>> intersection once
>>>>>>>>> 
>>>>>>>>> To handle all of that complexity we have to involve a
>>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>>>> currently for all pipelines.
>>>>>>>>> 
>>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>>>> CPU path
>>>>>>>>> rasterization.
>>>>>>>>> 
>>>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>>>> dominates its performance.
>>>>>>>>> 
>>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>>> 
>>>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>>>> case. Does
>>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>>>> SW
>>>>>>>>> pipeline for the polygon case?
>>>>>>>>> 
>>>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>>>> calls faster than drawPolygon as well...
>>>>>>>>> 
>>>>>>>>> ...jim
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Robert,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>>>> I'd
>>>>>>>>>> better add my findings.
>>>>>>>>>> 
>>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>>>> strokeLine commands as expected:
>>>>>>>>>> 
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>>>> Result:
>>>>>>>>>> 44fps
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>>>> Result:
>>>>>>>>>> 60fps
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>>>  examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>>> 
>>>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>>>> JavaFX
>>>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>>>> do think there's a bug here.
>>>>>>>>>> 
>>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>>>> slow" ;)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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(Op
>>>>>>>>>>> en%2C% 20%2
>>>>>>>>>>> 2In%
>>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>>>> 20%20A
>>>>>>>>>>> ND%2
>>>>>>>>>>> 0la
>>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>> 
>>>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>>>> least OSX and Windows and
>>>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>>> 
>>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>>>> across diverse platforms"
>>>>>>>>>>> 
>>>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>>>> (8u40)
>>>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>>>  performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>>> 
>>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>>>> performance that can be tracked?
>>>>>>>>>>> 
>>>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>>>> the best.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Possibly related:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>>>> count) command.
>>>>>>>>>>>> 
>>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>> 
>>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Build with ant
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Run with:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> # use strokeLine
>>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>>>> 20GB RAM
>>>>>>>>>>>> /
>>>>>>>>>>>> Radeon
>>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>>>> than using the convenience method.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Chris
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>>>  predetermined shader, but it shouldn't be that
>>>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>>>  AnimationTimer
>>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>>>  serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr??ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> 


From cnewland at chrisnewland.com  Thu Apr 16 20:36:32 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Thu, 16 Apr 2015 21:36:32 +0100
Subject: Canvas performance on Mac OS
In-Reply-To: <3eda52657ce2df280ee4f1893469516d.squirrel@excalibur.xssl.net>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
	<3eda52657ce2df280ee4f1893469516d.squirrel@excalibur.xssl.net>
Message-ID: <49de6041166a1098b60a52b6fe19346a.squirrel@excalibur.xssl.net>

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

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

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

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

Thanks a lot Jim and team for looking into this!

Cheers,

Chris


On Thu, April 16, 2015 09:39, Chris Newland wrote:
> Hi Jim,
>
>
> Thanks for looking into this.
>
>
> The patch definitely improves es2 performance on Debian Linux amd64 from
> around 33fps to around 53fps for me (nVidia FX580).
>
> I've made patched overlay builds of OpenJFX (Linux) 8 and 9 available on
> my OpenJFX CI server for anyone who wants to try it: http://108.61.191.178/
>
>
> Will test on OSX tonight.
>
>
> Cheers,
>
>
> Chris
>
>
>
> On Tue, April 14, 2015 20:16, Jim Graham wrote:
>
>> Hi Chris,
>>
>>
>>
>> We identified a fairly localized optimization that we might be able to
>> apply to enhance the performance of your Sierpinski program.  We don't
>> have any figures yet on whether this will improve other
>> applications/benchmarks that people have been discussing, but the
>> improvements with your Sierpinski program are quite dramatic on a number
>>  of platforms and GPUs.
>>
>> This issue is now being tracked as:
>> https://javafx-jira.kenai.com/browse/RT-40533
>>
>>
>>
>> If others could apply the indicated patch to an OpenJFX build and
>> provide feedback on any improvements (or bugs!) that they see, that
>> would help.  In the meantime, we have a lot of testing to do to verify
>> the correctness of the changes...
>>
>> ...jim
>>
>>
>>
>> On 4/8/15 9:25 AM, Chris Newland wrote:
>>
>>
>>> Hi Jim,
>>>
>>>
>>>
>>> I'll post the verbose prism output from my iMac when I get home.
>>>
>>>
>>>
>>> Just tried this on my Linux workstation and the performance gap is
>>> the same between es2 and sw so I don't think it's an OSX issue.
>>>
>>> uname -a Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2
>>> x86_64 GNU/Linux
>>>
>>>
>>>
>>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 20
>>> fps: 31
>>> fps: 32
>>> fps: 33
>>> fps: 35
>>> fps: 34
>>> fps: 33
>>>
>>>
>>>
>>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
>>> fps: 56
>>> fps: 60
>>> fps: 59
>>> fps: 60
>>> fps: 61
>>> fps: 61
>>> fps: 60
>>>
>>>
>>>
>>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>>> graphics card running driver 304.125
>>>
>>> Regards,
>>>
>>>
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>>
>>>
>>>> OK, I took the time to put my rMBP on a diet yesterday and find
>>>> room to install a 10.10 partition.  I get the same numbers for
>>>> Sierpinski
>>>> on 10.10, so my theory that something changed in the OGL
>>>> implementation for 10.10 doesn't hold water.
>>>>
>>>> But, I then tried it using the integrated graphics.  I get really
>>>> poor performance using the integrated Intel 4000 graphics, but I get
>>>>  great numbers on the discrete nVidia 650m.  It makes sense that
>>>> the Intel
>>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>>> shouldn't be taxing it that much to make that big of a difference.
>>>>
>>>> Just to be sure - is that iMac a dual graphics system, or is it
>>>> all-AMD-all-the-time?  You can see which GPU is being used if you
>>>> run it with -Dprism.verbose=true...
>>>>
>>>> ...jim
>>>>
>>>>
>>>>
>>>>
>>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>>
>>>>
>>>>
>>>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.
>>>>> Are
>>>>> you running a newer version of MacOS?
>>>>>
>>>>> ...jim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi Herv?,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's a valid question :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Probably because
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> a) All my non-UI graphics experience is with immediate-mode /
>>>>>> raster systems
>>>>>>
>>>>>> b) I'm interested in using JavaFX for particle effects /
>>>>>> demoscene / gaming so assumed (perhaps wrongly?) that
>>>>>> scenegraph was not the way to go for that due to the very large
>>>>>> number of nodes.
>>>>>>
>>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD
>>>>>> 6970M
>>>>>> 1024 MB
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23
>>>>>> fps: 18
>>>>>> fps: 25
>>>>>> fps: 18
>>>>>> fps: 23
>>>>>> fps: 23
>>>>>> fps: 19
>>>>>> fps: 25
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=sw -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> There are never more than 2500 filled triangles on screen. JDK
>>>>>> is 1.8.0_40
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would say there is a performance problem here? (or at least a
>>>>>>  need for documentation so as to set expectations for
>>>>>> gc.fillPolygon).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Why don't you use Nodes rather than Canvas ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks, that makes things much clearer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was surprised how much was going on under the hood of
>>>>>>>> GraphicsContext
>>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>>>  rasterizing where not.
>>>>>>>>
>>>>>>>> I've managed to find an anomaly with
>>>>>>>> GraphicsContext.fillPolygon
>>>>>>>> where the software pipeline achieves the full 60fps but ES2
>>>>>>>> can only manage 30-35fps. It uses lots of overlapping
>>>>>>>> filled triangles so I expect suffers from the problem you've
>>>>>>>>  described.
>>>>>>>>
>>>>>>>> SSCCE:
>>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main
>>>>>>>> /j
>>>>>>>> ava/ com/ch
>>>>>>>>
>>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>>
>>>>>>>> Was full frame rate canvas drawing 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
>>>>>>>>>>> %2
>>>>>>>>>>> 0(Op
>>>>>>>>>>> en%2C% 20%2 2In%
>>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(m
>>>>>>>>>>> aco sx)% 20%20A ND%2
>>>>>>>>>>> 0la
>>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>>
>>>>>>>>>>> Given that one of the One of the main reasons to use
>>>>>>>>>>> JFX
>>>>>>>>>>> for me is to be able to develop with one code base for
>>>>>>>>>>>  at least OSX and Windows and the official statement
>>>>>>>>>>> what JavaFX is for, i.e.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>>>  deploy rich client applications that operate
>>>>>>>>>>> consistently across diverse platforms"
>>>>>>>>>>>
>>>>>>>>>>> and the fact that this is clearly not the case
>>>>>>>>>>> currently (8u40) as soon as I do something else than
>>>>>>>>>>> simple forms, I run into performance/quality problems
>>>>>>>>>>> on the Mac, I am a bit unsure what to make of all
>>>>>>>>>>> that. Is Mac OSX a second-class citizen as far as dev
>>>>>>>>>>> resources are concerned?
>>>>>>>>>>>
>>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac
>>>>>>>>>>> graphics performance that can be tracked?
>>>>>>>>>>>
>>>>>>>>>>> I will file an issue with a simple test case and hope
>>>>>>>>>>>  for the best.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Possibly related:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can reproduce a massive (90%) performance drop on
>>>>>>>>>>>>  OSX
>>>>>>>>>>>> between drawing a wireframe polygon on a Canvas
>>>>>>>>>>>> using a series of gc.strokeLine(double x1, double
>>>>>>>>>>>> y1, double x2, double y2) commands versus using a
>>>>>>>>>>>> single gc.strokePolygon(double[] xPoints, double[]
>>>>>>>>>>>> yPoints, int count) command.
>>>>>>>>>>>>
>>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>>>  significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Build with ant
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Run with:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokeLine
>>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core
>>>>>>>>>>>> i7 /
>>>>>>>>>>>> 20GB RAM
>>>>>>>>>>>> /
>>>>>>>>>>>> Radeon
>>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints,
>>>>>>>>>>>> yPoints, nPoints, true, NGCanvas.STROKE_PATH) which
>>>>>>>>>>>>  involves significantly more work with adding to
>>>>>>>>>>>> and flushing a GrowableDataBuffer.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've not had time to dig any deeper than this but
>>>>>>>>>>>> it's surely a bug when building a poly manually is
>>>>>>>>>>>> 10x
>>>>>>>>>>>> faster than using the convenience method.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> In my opinion the whole graphics performance on
>>>>>>>>>>>>> MacOSX
>>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>>>  <krueger at lesspain.de>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The bad full screen performance is without the
>>>>>>>>>>>>>> arcs. It is just one call to fillRect, two to
>>>>>>>>>>>>>> strokeOval and one to fillOval, that's all. I
>>>>>>>>>>>>>> will build a simple test case and file an issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please file a Jira issue with a simple test
>>>>>>>>>>>>>>> case. Arcs are handled as a generalized shape
>>>>>>>>>>>>>>> rather than via a predetermined shader, but it
>>>>>>>>>>>>>>> shouldn't be that slow. Something else may be
>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another test might be to replace the arcs
>>>>>>>>>>>>>>> with rectangles or ellipses and see if the
>>>>>>>>>>>>>>> performance changes...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a super-simple animation implemented
>>>>>>>>>>>>>>>>  using AnimationTimer and Canvas where the
>>>>>>>>>>>>>>>> canvas just performs a few draw operations,
>>>>>>>>>>>>>>>> i.e. fills the screen with a color and then
>>>>>>>>>>>>>>>> draws and fills 2-3 circles and I have
>>>>>>>>>>>>>>>> already observed that each drawing operation
>>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10
>>>>>>>>>>>>>>>> arcs in addition to the circles, the CPU
>>>>>>>>>>>>>>>> load goes up to 30-40% on a Mac Book Pro for
>>>>>>>>>>>>>>>> a Canvas size of
>>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now I tested the animation in full screen
>>>>>>>>>>>>>>>> mode (only with a few circles) and playback
>>>>>>>>>>>>>>>> is unusable for a serious application (very
>>>>>>>>>>>>>>>> choppy). Is 2D canvas performance known to
>>>>>>>>>>>>>>>> be very bad on Mac or am I doing something
>>>>>>>>>>>>>>>> wrong? Are there workarounds for this?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr??ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>
>
>



From johan at lodgon.com  Thu Apr 16 20:41:10 2015
From: johan at lodgon.com (Johan Vos)
Date: Thu, 16 Apr 2015 22:41:10 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <0500EFE7-DC46-4A46-A37E-204AF87FD9DD@ultramixer.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
	<CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
	<0500EFE7-DC46-4A46-A37E-204AF87FD9DD@ultramixer.com>
Message-ID: <CABek58mQ4QXN2JqWJV8D2mMiR_h7neSbbEzcOSHAkoJAgipu4g@mail.gmail.com>

Yes, that is indeed what I'm doing.

- Johan

2015-04-16 22:05 GMT+02:00 Tobias Bley <tobi at ultramixer.com>:

> Hi Johan,
>
> I would like to test it on iPad 1 and iPhone 4, would it be possible now
> via JavaFXPorts-Gradle-Plugin?
>
> Best,
> Tobi
>
>
> > Am 16.04.2015 um 21:58 schrieb Johan Vos <johan at lodgon.com>:
> >
> > Hi Jim,
> >
> > On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
> > Excellent work!
> >
> > - Johan
> >
> > 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
> >
> >> Hi Chris,
> >>
> >> We identified a fairly localized optimization that we might be able to
> >> apply to enhance the performance of your Sierpinski program.  We don't
> have
> >> any figures yet on whether this will improve other
> applications/benchmarks
> >> that people have been discussing, but the improvements with your
> Sierpinski
> >> program are quite dramatic on a number of platforms and GPUs.
> >>
> >> This issue is now being tracked as: https://javafx-jira.kenai.com/
> >> browse/RT-40533
> >>
> >> If others could apply the indicated patch to an OpenJFX build and
> provide
> >> feedback on any improvements (or bugs!) that they see, that would
> help.  In
> >> the meantime, we have a lot of testing to do to verify the correctness
> of
> >> the changes...
> >>
> >>                        ...jim
> >>
> >>
> >> On 4/8/15 9:25 AM, Chris Newland wrote:
> >>
> >>> Hi Jim,
> >>>
> >>> I'll post the verbose prism output from my iMac when I get home.
> >>>
> >>> Just tried this on my Linux workstation and the performance gap is the
> >>> same between es2 and sw so I don't think it's an OSX issue.
> >>>
> >>> uname -a
> >>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64
> GNU/Linux
> >>>
> >>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
> >>> com.chrisnewland.demofx.standalone.Sierpinski
> >>> fps: 1
> >>> fps: 20
> >>> fps: 31
> >>> fps: 32
> >>> fps: 33
> >>> fps: 35
> >>> fps: 34
> >>> fps: 33
> >>>
> >>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
> >>> com.chrisnewland.demofx.standalone.Sierpinski
> >>> fps: 1
> >>> fps: 54
> >>> fps: 56
> >>> fps: 60
> >>> fps: 59
> >>> fps: 60
> >>> fps: 61
> >>> fps: 61
> >>> fps: 60
> >>>
> >>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
> >>> graphics card running driver 304.125
> >>>
> >>> Regards,
> >>>
> >>> Chris
> >>>
> >>>
> >>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
> >>>
> >>>> OK, I took the time to put my rMBP on a diet yesterday and find room
> to
> >>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
> >>>> 10.10,
> >>>> so my theory that something changed in the OGL implementation for
> 10.10
> >>>> doesn't hold water.
> >>>>
> >>>> But, I then tried it using the integrated graphics.  I get really poor
> >>>> performance using the integrated Intel 4000 graphics, but I get great
> >>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
> >>>> graphics wouldn't be as powerful as the discrete graphics, but we
> >>>> shouldn't be taxing it that much to make that big of a difference.
> >>>>
> >>>> Just to be sure - is that iMac a dual graphics system, or is it
> >>>> all-AMD-all-the-time?  You can see which GPU is being used if you run
> it
> >>>> with -Dprism.verbose=true...
> >>>>
> >>>> ...jim
> >>>>
> >>>>
> >>>> On 4/2/15 4:13 PM, Jim Graham wrote:
> >>>>
> >>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
> >>>>> running a newer version of MacOS?
> >>>>>
> >>>>> ...jim
> >>>>>
> >>>>>
> >>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
> >>>>>
> >>>>> Hi Herv?,
> >>>>>>
> >>>>>>
> >>>>>> That's a valid question :)
> >>>>>>
> >>>>>>
> >>>>>> Probably because
> >>>>>>
> >>>>>>
> >>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
> >>>>>> systems
> >>>>>>
> >>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
> >>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
> >>>>>> to go for that due to the very large number of nodes.
> >>>>>>
> >>>>>> Numbers for my Sierpinski filled triangle example:
> >>>>>>
> >>>>>>
> >>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
> >>>>>> 1024 MB
> >>>>>>
> >>>>>>
> >>>>>> java -Dprism.order=es2 -cp target/classes/
> >>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
> >>>>>> fps: 23
> >>>>>> fps: 18
> >>>>>> fps: 25
> >>>>>> fps: 18
> >>>>>> fps: 23
> >>>>>> fps: 23
> >>>>>> fps: 19
> >>>>>> fps: 25
> >>>>>>
> >>>>>>
> >>>>>> java -Dprism.order=sw -cp target/classes/
> >>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
> >>>>>> fps: 54
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>> fps: 60
> >>>>>>
> >>>>>>
> >>>>>> There are never more than 2500 filled triangles on screen. JDK is
> >>>>>> 1.8.0_40
> >>>>>>
> >>>>>>
> >>>>>> I would say there is a performance problem here? (or at least a need
> >>>>>> for documentation so as to set expectations for gc.fillPolygon).
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>>
> >>>>>> Chris
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
> >>>>>>
> >>>>>> Why don't you use Nodes rather than Canvas ?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Sent from my iPhone
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
> >>>>>>>> <cnewland at chrisnewland.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi Jim,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks, that makes things much clearer.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I was surprised how much was going on under the hood of
> >>>>>>>> GraphicsContext
> >>>>>>>> and hoped it was just magic glue that gave the best of GPU
> >>>>>>>> acceleration where available and immediate-mode-like simple
> >>>>>>>> rasterizing where not.
> >>>>>>>>
> >>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
> >>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
> >>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
> >>>>>>>> so I expect suffers from the problem you've described.
> >>>>>>>>
> >>>>>>>> SSCCE:
> >>>>>>>>
> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
> >>>>>>>> com/ch
> >>>>>>>>
> >>>>>>>> risnewland/demofx/standalone/Sierpinski.java
> >>>>>>>>
> >>>>>>>> Was full frame rate canvas drawing an expected use case for
> >>>>>>>> JavaFX or
> >>>>>>>> would I be better off with Graphics2D?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Chris
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
> >>>>>>>>> Hi Chris,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> drawLine() is a very simple primitive that can be optimized
> >>>>>>>>> with a GPU
> >>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
> >>>>>>>>> or a rounded rect - and we have optimized shaders for both
> >>>>>>>>> cases.  A large number of drawLine() calls turns into simply
> >>>>>>>>> accumulating a large vertex list and uploading it to the GPU
> >>>>>>>>> with an appropriate shader which is very fast.
> >>>>>>>>>
> >>>>>>>>> drawPolygon() is a very complex operation that involves things
> >>>>>>>>> like:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> - dealing with line joins between segments that don't exist for
> >>>>>>>>>  drawLine() - dealing with only rendering common points of
> >>>>>>>>> intersection once
> >>>>>>>>>
> >>>>>>>>> To handle all of that complexity we have to involve a
> >>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
> >>>>>>>>> the stroke attributes and interactions and computes a coverage
> >>>>>>>>> mask for each pixel in the region. We do that in software
> >>>>>>>>> currently for all pipelines.
> >>>>>>>>>
> >>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
> >>>>>>>>> CPU path
> >>>>>>>>> rasterization.
> >>>>>>>>>
> >>>>>>>>> For the SW pipeline, drawLine is a simplified case of
> >>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
> >>>>>>>>> dominates its performance.
> >>>>>>>>>
> >>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
> >>>>>>>>> with drawLine() performance (as long as there are no additional
> >>>>>>>>> rendering primitives interspersed in the set of lines).
> >>>>>>>>>
> >>>>>>>>> But, both should be on the same footing for the drawPolygon
> >>>>>>>>> case. Does
> >>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
> >>>>>>>>> SW
> >>>>>>>>> pipeline for the polygon case?
> >>>>>>>>>
> >>>>>>>>> One thing I noticed is that we have no optimized case for
> >>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
> >>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
> >>>>>>>>> rasterizer when it could instead compute the rounded/square
> >>>>>>>>> rectangle and render it more directly.  If we added that support
> >>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
> >>>>>>>>> calls faster than drawPolygon as well...
> >>>>>>>>>
> >>>>>>>>> ...jim
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Hi Robert,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
> >>>>>>>>>> investigate thoroughly but when I saw your question I thought
> >>>>>>>>>> I'd
> >>>>>>>>>> better add my findings.
> >>>>>>>>>>
> >>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
> >>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
> >>>>>>>>>> strokeLine commands as expected:
> >>>>>>>>>>
> >>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
> >>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
> >>>>>>>>>> Result:
> >>>>>>>>>> 44fps
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
> >>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
> >>>>>>>>>> Result:
> >>>>>>>>>> 60fps
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Will see if I can find the root cause as I've got plenty more
> >>>>>>>>>>  examples where ES2Pipeline performs horribly on my Mac which
> >>>>>>>>>> should have no problem throwing around a few thousand polys.
> >>>>>>>>>>
> >>>>>>>>>> I realise there's a *lot* of indirection involved in making
> >>>>>>>>>> JavaFX
> >>>>>>>>>> support such a wide range of underlying graphics systems but I
> >>>>>>>>>> do think there's a bug here.
> >>>>>>>>>>
> >>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
> >>>>>>>>>> slow" ;)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 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(Op
> >>>>>>>>>>> en%2C% 20%2
> >>>>>>>>>>> 2In%
> >>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
> >>>>>>>>>>> 20%20A
> >>>>>>>>>>> ND%2
> >>>>>>>>>>> 0la
> >>>>>>>>>>> bels%20in%20(performance)
> >>>>>>>>>>>
> >>>>>>>>>>> Given that one of the One of the main reasons to use JFX
> >>>>>>>>>>> for me is to be able to develop with one code base for at
> >>>>>>>>>>> least OSX and Windows and
> >>>>>>>>>>> the official statement what JavaFX is for, i.e.
> >>>>>>>>>>>
> >>>>>>>>>>> "JavaFX is a set of graphics and media packages that
> >>>>>>>>>>> enables developers to design, create, test, debug, and
> >>>>>>>>>>> deploy rich client applications that operate consistently
> >>>>>>>>>>> across diverse platforms"
> >>>>>>>>>>>
> >>>>>>>>>>> and the fact that this is clearly not the case currently
> >>>>>>>>>>> (8u40)
> >>>>>>>>>>> as soon as I do something else than simple forms, I run into
> >>>>>>>>>>>  performance/quality problems on the Mac, I am a bit unsure
> >>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
> >>>>>>>>>>> as far as dev resources are concerned?
> >>>>>>>>>>>
> >>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
> >>>>>>>>>>> performance that can be tracked?
> >>>>>>>>>>>
> >>>>>>>>>>> I will file an issue with a simple test case and hope for
> >>>>>>>>>>> the best.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
> >>>>>>>>>>> <cnewland at chrisnewland.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Possibly related:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
> >>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
> >>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
> >>>>>>>>>>>> double y2) commands versus using a single
> >>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
> >>>>>>>>>>>> count) command.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Creating the polygons manually with strokeLine() is
> >>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
> >>>>>>>>>>>> benchmarking project I've created:
> >>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Build with ant
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Run with:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> # use strokeLine
> >>>>>>>>>>>> ./run.sh -c 5000 -m line
> >>>>>>>>>>>> result: 60 (sixty) fps
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> # use strokePolygon
> >>>>>>>>>>>> ./run.sh -c 5000 -m poly
> >>>>>>>>>>>> result: 6 (six) fps
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
> >>>>>>>>>>>> 20GB RAM
> >>>>>>>>>>>> /
> >>>>>>>>>>>> Radeon
> >>>>>>>>>>>> 6970M 1024MB
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Looking at the code paths in
> >>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
> >>>>>>>>>>>> NGCanvas.STROKE_LINE)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
> >>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
> >>>>>>>>>>>> significantly more work with adding to and flushing a
> >>>>>>>>>>>> GrowableDataBuffer.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've not had time to dig any deeper than this but it's
> >>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
> >>>>>>>>>>>> than using the convenience method.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Chris
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
> >>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
> >>>>>>>>>>>>>> <krueger at lesspain.de>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The bad full screen performance is without the arcs.
> >>>>>>>>>>>>>> It is
> >>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
> >>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
> >>>>>>>>>>>>>> case and file an issue.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
> >>>>>>>>>>>>>> <james.graham at oracle.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Robert,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
> >>>>>>>>>>>>>>> Arcs
> >>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
> >>>>>>>>>>>>>>>  predetermined shader, but it shouldn't be that
> >>>>>>>>>>>>>>> slow. Something else may
> >>>>>>>>>>>>>>> be going on.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Another test might be to replace the arcs with
> >>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
> >>>>>>>>>>>>>>> changes...
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> ...jim
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I have a super-simple animation implemented using
> >>>>>>>>>>>>>>>>  AnimationTimer
> >>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
> >>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
> >>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
> >>>>>>>>>>>>>>>> have already observed that each drawing operation
> >>>>>>>>>>>>>>>> I add, results in
> >>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
> >>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
> >>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
> >>>>>>>>>>>>>>>> 600x600(!).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
> >>>>>>>>>>>>>>>> (only
> >>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
> >>>>>>>>>>>>>>>>  serious application (very choppy). Is 2D canvas
> >>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
> >>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
> >>>>>>>>>>>>>>>> this?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Robert
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Robert Kr????ger
> >>>>>>>>>>>>>> Managing Partner
> >>>>>>>>>>>>>> Lesspain GmbH & Co. KG
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> www.lesspain-software.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Robert Kr??ger
> >>>>>>>>>>> Managing Partner
> >>>>>>>>>>> Lesspain GmbH & Co. KG
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> www.lesspain-software.com
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
>
>

From matthieu at brouillard.fr  Thu Apr 16 22:24:33 2015
From: matthieu at brouillard.fr (Matthieu BROUILLARD)
Date: Fri, 17 Apr 2015 00:24:33 +0200
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <220D6C95-1D6D-4A88-AF11-F93D5AEB4343@reportmill.com>
References: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
	<220D6C95-1D6D-4A88-AF11-F93D5AEB4343@reportmill.com>
Message-ID: <CADsuJr_BAx4WhXQ4_eFXv7VwW-Ah5m4HAVYWGQdF6Qpgq5xFCA@mail.gmail.com>

In my company at least in the business (healthcare in hospitals) we target
JavaFX for (as a replacement of old app in Swing) we for sure cannot ask
our clients to change their computers/screen to have HiDPI... so having 5K
screens, yes in 2045 perhaps.


On Thu, Apr 16, 2015 at 7:12 PM, Jeff Martin <jeff at reportmill.com> wrote:

> I?m surprised about the font size problem - If I create a font with new
> Font(?Monaco?, 10), text shows up the same size as it does in Eclipse.
>
> I don?t think there is a solution for the blurry problem, however, because
> there is no way to disable Antialiasing. In Swing, I was able to get crisp
> rendering identical to eclipse by checking for very specific fonts/sizes
> and disabling TEXT_ANTIALIASING.
>
> The only solution in JavaFX may be to get a Retina monitor. This didn?t
> seem to be a terrible proposition to me last year, when it seemed like
> almost everything from phones to tablets to laptops had gone HiDPI. It?s
> taking forever for the desktop world to catch on, though. Apple is taking
> it?s time. Dell apparently has a nice 5k external, but it needs two mini
> display ports to drive it.
>
> jeff
>
>
> On Apr 16, 2015, at 9:28 AM, Damien Dudouit <ddudouit at clio.ch> wrote:
>
> > Hello,
> >
> > I'm experimenting with Java FX on a Windows 7 machine, using Java
> 1.8.0_40.
> >
> > The *javafx.scene.text.*Font javadoc says :
> >
> > *The size of a Font is described as being specified in points which are a
> > real world measurement of approximately 1/72 inch. *
> >
> > *[...] Note that the real world distances specified by the default
> > coordinate system only approximate point sizes as a rule of thumb and are
> > typically defaulted to screen pixels for most displays. *
> >
> > Java FX behaves as if the display dpi is 72 while in my case for instance
> > its about 96. 96/72 = 1.3333.
> >
> > So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10)
> as
> > a font on a javafx.scene.control.TextArea, text appears a lot smaller
> than
> > in my eclipse editor configured with the same font.
> > Obviously, I get about the same visual size if I use a font size of 13 in
> > Java FX while using the same font in size 10 in Eclipse.
> >
> > I guess I could set scaling somehow in my Java FX code. But using
> scaling,
> > I imagine that text has little chance to display as crisp as it should.
> >
> > In fact, trying to compare the pixel output of Eclipse with font size 10
> > and Java FX in font size 13 (or 13.333), the Java FX one is slightly
> blurry.
> >
> > What can be done in Java FX when an application needs text as clear as
> > possible, for instance if the application is a text editor ?
> >
> > What is the correct approach in a Java FX app so that it respect the
> > default font size configured at the OS level ?
> >
> >
> > Thanks a lot in advance,
> >
> > Damien
> >
> >
> > public final class MyApplication extends Application {
> >
> >  public static void main(String[] args) {
> >    launch(args);
> >  }
> >
> >  @Override
> >  public void start(Stage primaryStage) {
> >    TextArea editor = new TextArea();
> >
> >    editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));
> >
> >    primaryStage.setScene(new Scene(editor));
> >    primaryStage.show();
> >
> >    System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
> >  }
> > }
>
>

From mikegps1 at gmail.com  Thu Apr 16 22:43:13 2015
From: mikegps1 at gmail.com (Mike)
Date: Thu, 16 Apr 2015 15:43:13 -0700
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <CADsuJr_BAx4WhXQ4_eFXv7VwW-Ah5m4HAVYWGQdF6Qpgq5xFCA@mail.gmail.com>
References: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
	<220D6C95-1D6D-4A88-AF11-F93D5AEB4343@reportmill.com>
	<CADsuJr_BAx4WhXQ4_eFXv7VwW-Ah5m4HAVYWGQdF6Qpgq5xFCA@mail.gmail.com>
Message-ID: <6F49AFDD-6106-4E43-82B1-70F506ED0E36@gmail.com>

This has caused us a lot of sleepless days 

Blur issue and fonts 
Cross platform scaling 



Sent from my iPhone

> On Apr 16, 2015, at 3:24 PM, Matthieu BROUILLARD <matthieu at brouillard.fr> wrote:
> 
> In my company at least in the business (healthcare in hospitals) we target
> JavaFX for (as a replacement of old app in Swing) we for sure cannot ask
> our clients to change their computers/screen to have HiDPI... so having 5K
> screens, yes in 2045 perhaps.
> 
> 
>> On Thu, Apr 16, 2015 at 7:12 PM, Jeff Martin <jeff at reportmill.com> wrote:
>> 
>> I?m surprised about the font size problem - If I create a font with new
>> Font(?Monaco?, 10), text shows up the same size as it does in Eclipse.
>> 
>> I don?t think there is a solution for the blurry problem, however, because
>> there is no way to disable Antialiasing. In Swing, I was able to get crisp
>> rendering identical to eclipse by checking for very specific fonts/sizes
>> and disabling TEXT_ANTIALIASING.
>> 
>> The only solution in JavaFX may be to get a Retina monitor. This didn?t
>> seem to be a terrible proposition to me last year, when it seemed like
>> almost everything from phones to tablets to laptops had gone HiDPI. It?s
>> taking forever for the desktop world to catch on, though. Apple is taking
>> it?s time. Dell apparently has a nice 5k external, but it needs two mini
>> display ports to drive it.
>> 
>> jeff
>> 
>> 
>>> On Apr 16, 2015, at 9:28 AM, Damien Dudouit <ddudouit at clio.ch> wrote:
>>> 
>>> Hello,
>>> 
>>> I'm experimenting with Java FX on a Windows 7 machine, using Java
>> 1.8.0_40.
>>> 
>>> The *javafx.scene.text.*Font javadoc says :
>>> 
>>> *The size of a Font is described as being specified in points which are a
>>> real world measurement of approximately 1/72 inch. *
>>> 
>>> *[...] Note that the real world distances specified by the default
>>> coordinate system only approximate point sizes as a rule of thumb and are
>>> typically defaulted to screen pixels for most displays. *
>>> 
>>> Java FX behaves as if the display dpi is 72 while in my case for instance
>>> its about 96. 96/72 = 1.3333.
>>> 
>>> So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10)
>> as
>>> a font on a javafx.scene.control.TextArea, text appears a lot smaller
>> than
>>> in my eclipse editor configured with the same font.
>>> Obviously, I get about the same visual size if I use a font size of 13 in
>>> Java FX while using the same font in size 10 in Eclipse.
>>> 
>>> I guess I could set scaling somehow in my Java FX code. But using
>> scaling,
>>> I imagine that text has little chance to display as crisp as it should.
>>> 
>>> In fact, trying to compare the pixel output of Eclipse with font size 10
>>> and Java FX in font size 13 (or 13.333), the Java FX one is slightly
>> blurry.
>>> 
>>> What can be done in Java FX when an application needs text as clear as
>>> possible, for instance if the application is a text editor ?
>>> 
>>> What is the correct approach in a Java FX app so that it respect the
>>> default font size configured at the OS level ?
>>> 
>>> 
>>> Thanks a lot in advance,
>>> 
>>> Damien
>>> 
>>> 
>>> public final class MyApplication extends Application {
>>> 
>>> public static void main(String[] args) {
>>>   launch(args);
>>> }
>>> 
>>> @Override
>>> public void start(Stage primaryStage) {
>>>   TextArea editor = new TextArea();
>>> 
>>>   editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));
>>> 
>>>   primaryStage.setScene(new Scene(editor));
>>>   primaryStage.show();
>>> 
>>>   System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
>>> }
>>> }
>> 
>> 

From jeff at reportmill.com  Thu Apr 16 23:17:46 2015
From: jeff at reportmill.com (Jeff Martin)
Date: Thu, 16 Apr 2015 18:17:46 -0500
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <CADsuJr_BAx4WhXQ4_eFXv7VwW-Ah5m4HAVYWGQdF6Qpgq5xFCA@mail.gmail.com>
References: <CAAJRru3jwsYzTAKzciAv6uU2kEbpLwTkTC0ML8qq7vBL40tKqA@mail.gmail.com>
	<220D6C95-1D6D-4A88-AF11-F93D5AEB4343@reportmill.com>
	<CADsuJr_BAx4WhXQ4_eFXv7VwW-Ah5m4HAVYWGQdF6Qpgq5xFCA@mail.gmail.com>
Message-ID: <B10C4519-8337-47FE-B5CE-AE4FF2AC0EBB@reportmill.com>

I should have included a smiley when I suggested a 5k Retina monitor as a ?workaround?. :-)

Also, I should have mentioned that I was able to improve my text rendering significantly with:

	myText.setFontSmoothingType(FontSmoothingType.LCD)

It isn?t as crisp as Eclipse, but I believe the text rendering is as good as Xcode, which renders text with antialiasing.

jeff


On Apr 16, 2015, at 5:24 PM, Matthieu BROUILLARD <matthieu at brouillard.fr> wrote:

> In my company at least in the business (healthcare in hospitals) we target JavaFX for (as a replacement of old app in Swing) we for sure cannot ask our clients to change their computers/screen to have HiDPI... so having 5K screens, yes in 2045 perhaps.
> 
> 
> On Thu, Apr 16, 2015 at 7:12 PM, Jeff Martin <jeff at reportmill.com> wrote:
> I?m surprised about the font size problem - If I create a font with new Font(?Monaco?, 10), text shows up the same size as it does in Eclipse.
> 
> I don?t think there is a solution for the blurry problem, however, because there is no way to disable Antialiasing. In Swing, I was able to get crisp rendering identical to eclipse by checking for very specific fonts/sizes and disabling TEXT_ANTIALIASING.
> 
> The only solution in JavaFX may be to get a Retina monitor. This didn?t seem to be a terrible proposition to me last year, when it seemed like almost everything from phones to tablets to laptops had gone HiDPI. It?s taking forever for the desktop world to catch on, though. Apple is taking it?s time. Dell apparently has a nice 5k external, but it needs two mini display ports to drive it.
> 
> jeff
> 
> 
> On Apr 16, 2015, at 9:28 AM, Damien Dudouit <ddudouit at clio.ch> wrote:
> 
> > Hello,
> >
> > I'm experimenting with Java FX on a Windows 7 machine, using Java 1.8.0_40.
> >
> > The *javafx.scene.text.*Font javadoc says :
> >
> > *The size of a Font is described as being specified in points which are a
> > real world measurement of approximately 1/72 inch. *
> >
> > *[...] Note that the real world distances specified by the default
> > coordinate system only approximate point sizes as a rule of thumb and are
> > typically defaulted to screen pixels for most displays. *
> >
> > Java FX behaves as if the display dpi is 72 while in my case for instance
> > its about 96. 96/72 = 1.3333.
> >
> > So for instance if I set Font.font("Consolas", FontPosture.REGULAR, 10) as
> > a font on a javafx.scene.control.TextArea, text appears a lot smaller than
> > in my eclipse editor configured with the same font.
> > Obviously, I get about the same visual size if I use a font size of 13 in
> > Java FX while using the same font in size 10 in Eclipse.
> >
> > I guess I could set scaling somehow in my Java FX code. But using scaling,
> > I imagine that text has little chance to display as crisp as it should.
> >
> > In fact, trying to compare the pixel output of Eclipse with font size 10
> > and Java FX in font size 13 (or 13.333), the Java FX one is slightly blurry.
> >
> > What can be done in Java FX when an application needs text as clear as
> > possible, for instance if the application is a text editor ?
> >
> > What is the correct approach in a Java FX app so that it respect the
> > default font size configured at the OS level ?
> >
> >
> > Thanks a lot in advance,
> >
> > Damien
> >
> >
> > public final class MyApplication extends Application {
> >
> >  public static void main(String[] args) {
> >    launch(args);
> >  }
> >
> >  @Override
> >  public void start(Stage primaryStage) {
> >    TextArea editor = new TextArea();
> >
> >    editor.setFont(Font.font("Consolas", FontPosture.REGULAR, 10));
> >
> >    primaryStage.setScene(new Scene(editor));
> >    primaryStage.show();
> >
> >    System.out.println(Toolkit.getDefaultToolkit().getScreenResolution());
> >  }
> > }
> 
> 


From ryan at jaeb.ca  Fri Apr 17 04:31:54 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Thu, 16 Apr 2015 22:31:54 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAOrfuJ1uUiWJushy2j7iexWJEwe8qWw2GMqTnDSbX3nDwmJgpA@mail.gmail.com>

I want to highlight something that was clarified for me on the discuss
alias.

On the bugs.java.com page there's a section entitled "Submit a Code Fix or
Test Case".  I misinterpreted it to be part of the guidelines for
submitting a bug and have been under the impression that I would be
required to follow the linked contributor guidelines, including achieving a
JBS role of author, if I want to submit a bug report that includes a test
case (which is expected as far as I know).

This is not the case.  For anyone landing on bugs.java.com, there are
basically no requirements for submitting a bug via the linked form, even if
you're including a test case as part of the bug report.

I'd like to apologize if my misinterpretation inadvertently caused any
misinformation to be spread on this list and I hope the clarification is
useful to anyone that may be making the same erroneous assumption I did.

Ryan Jaeb


On Tue, Apr 14, 2015 at 4:20 PM, Kevin Rushforth <kevin.rushforth at oracle.com
> wrote:

> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The
> JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK
> Community. With the OpenJFX Project being a part of this Community, it is
> time for us to move away from our separate bug tracker and make use of JBS.
> This will allow us to leverage the greater infrastructure investments being
> made and lessen the burden of having to maintain our own infrastructure,
> and consolidates all JDK bugs in one place. The target date for this
> transition is the second half of May.
>
> The issues currently in the RT project in JavaFX JIRA will be folded into
> the JDK project in JBS. Details will follow on the mapping, but here are
> the highlights:
>
> - A new "javafx" component will be created in the JDK project
> - Most existing JavaFX JIRA components will be sub-components of the
> "javafx" component
> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID
> will be maintained by JBS such that searching for RT-nnnnn will take you to
> the right JDK-mmmmmmm bug.
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx).
>
> Our advice to those of you actively involved and participating in the
> OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by
> signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary
> first step in contributing to any OpenJDK Project, including OpenJFX. It
> allows you to provide patches that we might accept for OpenJFX, and is also
> a step along the path to becoming an Author. The general guideline [7] is
> that the Author role may be requested by a Project Contributor who has
> contributed two non-trivial patches that have been accepted and pushed.
>
> As part of this transition, we will enable anonymous viewing of bugs (no
> need to login just to look at a bug) and they will be easily searchable
> online.
>
> We apologize for the inconvenience caused to OpenJFX Participants by this
> upcoming change to the bug database write access policy. We really
> appreciate your commitment to improving and growing the JavaFX technology.
>
> -- Kevin
>
>
> [1] https://javafx-jira.kenai.com/
> [2] https://bugs.openjdk.java.net/
> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [3] http://bugs.java.com/
> [5] http://openjdk.java.net/contribute/
> [6] http://www.oracle.com/technetwork/oca-405177.pdf
> [7] http://openjdk.java.net/projects/#project-author
>
>

From ryan at jaeb.ca  Fri Apr 17 04:56:20 2015
From: ryan at jaeb.ca (Ryan Jaeb)
Date: Thu, 16 Apr 2015 22:56:20 -0600
Subject: JavaFX JIRA issues moving to JBS
In-Reply-To: <552D92B8.4030509@oracle.com>
References: <552D92B8.4030509@oracle.com>
Message-ID: <CAOrfuJ1=JVPUPrdZCrizmxAQ=PVifE0M8ZvvD7F4Xu=MZjAN9w@mail.gmail.com>

Of course I forgot to be explicit about the main thing that was important
to the discuss alias when I posted that last message.  You do NOT need to
sign the OCA to contribute a bug via bugs.java.com.

I'm not actually sure why the page at bugs.java.com directs people to the
contributor agreement because, as I understand it now, none of it applies
to submitting a bug using bugs.java.com.

Ryan Jaeb

On Tue, Apr 14, 2015 at 4:20 PM, Kevin Rushforth <kevin.rushforth at oracle.com
> wrote:

> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The
> JDK Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK
> Community. With the OpenJFX Project being a part of this Community, it is
> time for us to move away from our separate bug tracker and make use of JBS.
> This will allow us to leverage the greater infrastructure investments being
> made and lessen the burden of having to maintain our own infrastructure,
> and consolidates all JDK bugs in one place. The target date for this
> transition is the second half of May.
>
> The issues currently in the RT project in JavaFX JIRA will be folded into
> the JDK project in JBS. Details will follow on the mapping, but here are
> the highlights:
>
> - A new "javafx" component will be created in the JDK project
> - Most existing JavaFX JIRA components will be sub-components of the
> "javafx" component
> - The mapping from existing "RT-nnnnn" bug ID to new "JDK-mmmmmmm" bug ID
> will be maintained by JBS such that searching for RT-nnnnn will take you to
> the right JDK-mmmmmmm bug.
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx).
>
> Our advice to those of you actively involved and participating in the
> OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by
> signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary
> first step in contributing to any OpenJDK Project, including OpenJFX. It
> allows you to provide patches that we might accept for OpenJFX, and is also
> a step along the path to becoming an Author. The general guideline [7] is
> that the Author role may be requested by a Project Contributor who has
> contributed two non-trivial patches that have been accepted and pushed.
>
> As part of this transition, we will enable anonymous viewing of bugs (no
> need to login just to look at a bug) and they will be easily searchable
> online.
>
> We apologize for the inconvenience caused to OpenJFX Participants by this
> upcoming change to the bug database write access policy. We really
> appreciate your commitment to improving and growing the JavaFX technology.
>
> -- Kevin
>
>
> [1] https://javafx-jira.kenai.com/
> [2] https://bugs.openjdk.java.net/
> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [3] http://bugs.java.com/
> [5] http://openjdk.java.net/contribute/
> [6] http://www.oracle.com/technetwork/oca-405177.pdf
> [7] http://openjdk.java.net/projects/#project-author
>
>

From r.lichtenberger at gmail.com  Fri Apr 17 05:51:04 2015
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Fri, 17 Apr 2015 07:51:04 +0200
Subject: Some questions about participating in development
Message-ID: <55309F48.2020502@gmail.com>

Hello everyone, since I recently spammed https://javafx-jira.kenai.com 
with bug reports :-), I decided it's time to take the next step and 
contribute patches.

With the help of 
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX I was 
able to checkout & build the rt module and execute gradle test, which 
BTW reported:
Exception in thread "JavaFX Application Thread" Exception in thread 
"JavaFX Application Thread"
javafx.scene.web.JavaScriptBridgeTest > testBridgeBadOverloading FAILED
     java.lang.AssertionError: caught unexpected exception: 
netscape.javascript.JSException: TypeError: 'undefined' is not a 
function (evaluating 'sb['append)int)'](123)')
         at org.junit.Assert.fail(Assert.java:91)
         at 
javafx.scene.web.JavaScriptBridgeTest.executeShouldFail(JavaScriptBridgeTest.java:370)
         at 
javafx.scene.web.JavaScriptBridgeTest.executeShouldFail(JavaScriptBridgeTest.java:374)
         at 
javafx.scene.web.JavaScriptBridgeTest.lambda$testBridgeBadOverloading$84(JavaScriptBridgeTest.java:424)

All other tests (loads of them, very nice!) have executed successfully.

I have also successfully executed gradle zips.

Now I wanted to start using an IDE. Under 
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX there are 
gradle tasks under section "IDE tasks" for IDEA and Netbeans project 
creation. These tasks are missing from my output of gradle tasks. Is 
there anything I forgot to install? Any unseen dependencies? What is the 
recommended / most used IDE of JavaFX developers?

Also how do I submit patches? I already have signed (but still need to 
send ...) the OCA. There is no way (for me) to attach anything in JIRA. 
Should I send patches to this list?

Best regards,
Robert Lichtenberger


From kirill.kirichenko at oracle.com  Fri Apr 17 12:47:54 2015
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Fri, 17 Apr 2015 15:47:54 +0300
Subject: [8u60] Request for review: RT-39297: FXM player fails to exit
Message-ID: <553100FA.10303@oracle.com>

Hi Alexander.
Could you please review this fix for flvdemux.c.
gst_pad_pull_range in the code above the change may return FLOW_ERROR is 
the buffer is of some enormous size. We should react to the error.

Also some files play well but don't receive EOS or Error because is 
coming with presentation timestamp which is far ahead te current time. 
So this isn't a erroneous situation but takes time to finish.

webrev: https://javafx-jira.kenai.com/browse/RT-39297
jira: http://cr.openjdk.java.net/~stayer/RT-38079

From kirill.kirichenko at oracle.com  Fri Apr 17 12:50:03 2015
From: kirill.kirichenko at oracle.com (Kirill Kirichenko)
Date: Fri, 17 Apr 2015 15:50:03 +0300
Subject: [8u60] Request for review: RT-39297: FXM player fails to exit
In-Reply-To: <553100FA.10303@oracle.com>
References: <553100FA.10303@oracle.com>
Message-ID: <5531017B.7030303@oracle.com>

Correct jira link: https://javafx-jira.kenai.com/browse/RT-38079

On 17.04.2015 15:47, Kirill Kirichenko wrote:
> Hi Alexander.
> Could you please review this fix for flvdemux.c.
> gst_pad_pull_range in the code above the change may return FLOW_ERROR is
> the buffer is of some enormous size. We should react to the error.
>
> Also some files play well but don't receive EOS or Error because is
> coming with presentation timestamp which is far ahead te current time.
> So this isn't a erroneous situation but takes time to finish.
>
> webrev: https://javafx-jira.kenai.com/browse/RT-39297
> jira: http://cr.openjdk.java.net/~stayer/RT-38079

From kevin.rushforth at oracle.com  Fri Apr 17 14:02:53 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 17 Apr 2015 07:02:53 -0700
Subject: Some questions about participating in development
In-Reply-To: <55309F48.2020502@gmail.com>
References: <55309F48.2020502@gmail.com>
Message-ID: <5531128D.5040800@oracle.com>

Hi Robert,

Glad to hear it. The reason for the test failure is that the webkit 
native library (jfxwebkit) isn't built by default, but is copied from 
the JDK you use to build the rest of FX. Any number of interesting 
errors can happen if you have a mismatch in the native library versus 
the rest of WebKit. This particular unit test changed as part of the 
wekbkit upgrade, so I guess you have an old (pre-upgrade) version of the 
native library and a new (post-update) version of the Java code and unit 
tests for WebView. The solution would be to use JDK 8u60-b08 or later to 
build FX.

As for IDE, I use NetBeans, but not the gradle plugin for NB. I open the 
projects under rt/netbeans with NB 8 and it works for me. Others on our 
team use IntelliJ.

If you have a patch for a specific issue, it might be easiest to e-mail 
the patch to the assignee and they can attach it (just like we ask bug 
reporters to do for images, larger test programs, etc). Also, I will 
volunteer to attach a patch you send to any issue.

-- Kevin


Robert Lichtenberger wrote:
> Hello everyone, since I recently spammed https://javafx-jira.kenai.com 
> with bug reports :-), I decided it's time to take the next step and 
> contribute patches.
>
> With the help of 
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX I was 
> able to checkout & build the rt module and execute gradle test, which 
> BTW reported:
> Exception in thread "JavaFX Application Thread" Exception in thread 
> "JavaFX Application Thread"
> javafx.scene.web.JavaScriptBridgeTest > testBridgeBadOverloading FAILED
>     java.lang.AssertionError: caught unexpected exception: 
> netscape.javascript.JSException: TypeError: 'undefined' is not a 
> function (evaluating 'sb['append)int)'](123)')
>         at org.junit.Assert.fail(Assert.java:91)
>         at 
> javafx.scene.web.JavaScriptBridgeTest.executeShouldFail(JavaScriptBridgeTest.java:370) 
>
>         at 
> javafx.scene.web.JavaScriptBridgeTest.executeShouldFail(JavaScriptBridgeTest.java:374) 
>
>         at 
> javafx.scene.web.JavaScriptBridgeTest.lambda$testBridgeBadOverloading$84(JavaScriptBridgeTest.java:424) 
>
>
> All other tests (loads of them, very nice!) have executed successfully.
>
> I have also successfully executed gradle zips.
>
> Now I wanted to start using an IDE. Under 
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX there 
> are gradle tasks under section "IDE tasks" for IDEA and Netbeans 
> project creation. These tasks are missing from my output of gradle 
> tasks. Is there anything I forgot to install? Any unseen dependencies? 
> What is the recommended / most used IDE of JavaFX developers?
>
> Also how do I submit patches? I already have signed (but still need to 
> send ...) the OCA. There is no way (for me) to attach anything in 
> JIRA. Should I send patches to this list?
>
> Best regards,
> Robert Lichtenberger
>

From vadim.pakhnushev at oracle.com  Fri Apr 17 14:30:20 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 17 Apr 2015 17:30:20 +0300
Subject: In(Sanity) Testing Mondays
Message-ID: <553118FC.5060503@oracle.com>

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 1pm 
PDT.

Happy testing!

Thanks,
Vadim

From anton.tarasov at oracle.com  Fri Apr 17 15:35:36 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Fri, 17 Apr 2015 18:35:36 +0300
Subject: [9] post-commit notification: RT-40529 Java crashes when trying to
	render go.com
Message-ID: <55312848.90602@oracle.com>

JIRA: https://javafx-jira.kenai.com/browse/RT-40529
webrev: http://cr.openjdk.java.net/~ant/RT-40529/webrev.0

Regards,
Anton.

From james.graham at oracle.com  Mon Apr 20 03:25:56 2015
From: james.graham at oracle.com (Jim Graham)
Date: Sun, 19 Apr 2015 20:25:56 -0700
Subject: Canvas performance on Mac OS
In-Reply-To: <CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>	<5515C483.9030901@oracle.com>	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>	<55199E52.9090503@oracle.com>	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>	<551DCD2F.8080900@oracle.com>
	<5524654C.2060500@oracle.com>	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>	<552D67A3.7060004@oracle.com>
	<CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
Message-ID: <553471C4.2060104@oracle.com>

Is that on Sierpinski?  The main question I still have is whether this 
helps other apps.  The usage pattern in Sierpinski is fairly specific 
and may not translate to all apps (we're still planning on doing this as 
it is an easy improvement that doesn't seem to have a down-side, but I 
don't want to break out any champagne if it is just this one benchmark)...

			...jim

On 4/16/15 12:58 PM, Johan Vos wrote:
> Hi Jim,
>
> On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
> Excellent work!
>
> - Johan
>
> 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>
>> Hi Chris,
>>
>> We identified a fairly localized optimization that we might be able to
>> apply to enhance the performance of your Sierpinski program.  We don't have
>> any figures yet on whether this will improve other applications/benchmarks
>> that people have been discussing, but the improvements with your Sierpinski
>> program are quite dramatic on a number of platforms and GPUs.
>>
>> This issue is now being tracked as: https://javafx-jira.kenai.com/
>> browse/RT-40533
>>
>> If others could apply the indicated patch to an OpenJFX build and provide
>> feedback on any improvements (or bugs!) that they see, that would help.  In
>> the meantime, we have a lot of testing to do to verify the correctness of
>> the changes...
>>
>>                          ...jim
>>
>>
>> On 4/8/15 9:25 AM, Chris Newland wrote:
>>
>>> Hi Jim,
>>>
>>> I'll post the verbose prism output from my iMac when I get home.
>>>
>>> Just tried this on my Linux workstation and the performance gap is the
>>> same between es2 and sw so I don't think it's an OSX issue.
>>>
>>> uname -a
>>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>>>
>>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 20
>>> fps: 31
>>> fps: 32
>>> fps: 33
>>> fps: 35
>>> fps: 34
>>> fps: 33
>>>
>>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>>> com.chrisnewland.demofx.standalone.Sierpinski
>>> fps: 1
>>> fps: 54
>>> fps: 56
>>> fps: 60
>>> fps: 59
>>> fps: 60
>>> fps: 61
>>> fps: 61
>>> fps: 60
>>>
>>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>>> graphics card running driver 304.125
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
>>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>>
>>>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
>>>> 10.10,
>>>> so my theory that something changed in the OGL implementation for 10.10
>>>> doesn't hold water.
>>>>
>>>> But, I then tried it using the integrated graphics.  I get really poor
>>>> performance using the integrated Intel 4000 graphics, but I get great
>>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>>> shouldn't be taxing it that much to make that big of a difference.
>>>>
>>>> Just to be sure - is that iMac a dual graphics system, or is it
>>>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>>>> with -Dprism.verbose=true...
>>>>
>>>> ...jim
>>>>
>>>>
>>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>>
>>>>   On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>>>> running a newer version of MacOS?
>>>>>
>>>>> ...jim
>>>>>
>>>>>
>>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>>
>>>>>   Hi Herv?,
>>>>>>
>>>>>>
>>>>>> That's a valid question :)
>>>>>>
>>>>>>
>>>>>> Probably because
>>>>>>
>>>>>>
>>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>>>> systems
>>>>>>
>>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>>>> to go for that due to the very large number of nodes.
>>>>>>
>>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>>
>>>>>>
>>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>>> 1024 MB
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 23
>>>>>> fps: 18
>>>>>> fps: 25
>>>>>> fps: 18
>>>>>> fps: 23
>>>>>> fps: 23
>>>>>> fps: 19
>>>>>> fps: 25
>>>>>>
>>>>>>
>>>>>> java -Dprism.order=sw -cp target/classes/
>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>> fps: 54
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>> fps: 60
>>>>>>
>>>>>>
>>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>>> 1.8.0_40
>>>>>>
>>>>>>
>>>>>> I would say there is a performance problem here? (or at least a need
>>>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>>
>>>>>>   Why don't you use Nodes rather than Canvas ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks, that makes things much clearer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was surprised how much was going on under the hood of
>>>>>>>> GraphicsContext
>>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>>> rasterizing where not.
>>>>>>>>
>>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>>>> so I expect suffers from the problem you've described.
>>>>>>>>
>>>>>>>> SSCCE:
>>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>>>> com/ch
>>>>>>>>
>>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>>
>>>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>>>> JavaFX or
>>>>>>>> would I be better off with Graphics2D?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>>>> with a GPU
>>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>>>> with an appropriate shader which is very fast.
>>>>>>>>>
>>>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>>>> like:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>>>    drawLine() - dealing with only rendering common points of
>>>>>>>>> intersection once
>>>>>>>>>
>>>>>>>>> To handle all of that complexity we have to involve a
>>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>>>> currently for all pipelines.
>>>>>>>>>
>>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>>>> CPU path
>>>>>>>>> rasterization.
>>>>>>>>>
>>>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>>>> dominates its performance.
>>>>>>>>>
>>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>>>
>>>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>>>> case. Does
>>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>>>> SW
>>>>>>>>> pipeline for the polygon case?
>>>>>>>>>
>>>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>>>> calls faster than drawPolygon as well...
>>>>>>>>>
>>>>>>>>> ...jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Robert,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>>>> I'd
>>>>>>>>>> better add my findings.
>>>>>>>>>>
>>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>>>> strokeLine commands as expected:
>>>>>>>>>>
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>>>> Result:
>>>>>>>>>> 44fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>>>> Result:
>>>>>>>>>> 60fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>>>    examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>>>
>>>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>>>> JavaFX
>>>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>>>> do think there's a bug here.
>>>>>>>>>>
>>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>>>> slow" ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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(Op
>>>>>>>>>>> en%2C% 20%2
>>>>>>>>>>> 2In%
>>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>>>> 20%20A
>>>>>>>>>>> ND%2
>>>>>>>>>>> 0la
>>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>>
>>>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>>>> least OSX and Windows and
>>>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>>>
>>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>>>> across diverse platforms"
>>>>>>>>>>>
>>>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>>>> (8u40)
>>>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>>>    performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>>>
>>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>>>> performance that can be tracked?
>>>>>>>>>>>
>>>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>>>> the best.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   Possibly related:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>>>> count) command.
>>>>>>>>>>>>
>>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>>
>>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Build with ant
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Run with:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokeLine
>>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>>>> 20GB RAM
>>>>>>>>>>>> /
>>>>>>>>>>>> Radeon
>>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>>>> than using the convenience method.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Hi Robert,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>>>    predetermined shader, but it shouldn't be that
>>>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>>>    AnimationTimer
>>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>>>    serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Kr??ger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>

From johan at lodgon.com  Mon Apr 20 06:15:29 2015
From: johan at lodgon.com (Johan Vos)
Date: Mon, 20 Apr 2015 08:15:29 +0200
Subject: Canvas performance on Mac OS
In-Reply-To: <553471C4.2060104@oracle.com>
References: <CAEnqZEWn2hKhj4nZieNOcEVmtGWafHoX2Yz64ArZs=J8qUu+oQ@mail.gmail.com>
	<5515C483.9030901@oracle.com>
	<CAEnqZEUox+GAeZbzSzYQQVuJ6krWjG+Dz-mByyyJ7cA9ju0SmA@mail.gmail.com>
	<E3A620A9-6549-4EE7-8DD9-A1E4A15C57A8@ultramixer.com>
	<caea8861b94bd8dd328de1267b8cff22.squirrel@excalibur.xssl.net>
	<CAEnqZEUPQc_ofjks4ArWsF8dYabfjNmqukMBH1MxnO8i2kUg_A@mail.gmail.com>
	<c9d42f64a9d324683b39a1e8e12954e8.squirrel@excalibur.xssl.net>
	<55199E52.9090503@oracle.com>
	<a88905f89b62d2bf2f21049d90b1159b.squirrel@excalibur.xssl.net>
	<9AA17C6D-2B5D-407A-A6F5-164221C05483@gmail.com>
	<50c9b8ad2824e658caac6730f73fa931.squirrel@excalibur.xssl.net>
	<551DCD2F.8080900@oracle.com> <5524654C.2060500@oracle.com>
	<058cf650a9ddaa367333bbca1399f8eb.squirrel@excalibur.xssl.net>
	<552D67A3.7060004@oracle.com>
	<CABek58kAjw9YR0LgCUp2fNBhTFxsXeGRg-B7fvD7hcq97Z706w@mail.gmail.com>
	<553471C4.2060104@oracle.com>
Message-ID: <CABek58niqO+0+srqUVysG3oKH-jpBEWt8Y_j6cA0nXQywq9UMw@mail.gmail.com>

Yes, that is on the benchmark that includes Sierpinski.
I was aware this was a rather specific case. Typical scenegraph rendering
already was much more performant on iOS, so I didn't expect real
improvements there. Of course, any changes that help improve the
performance are very welcome.

- Johan

2015-04-20 5:25 GMT+02:00 Jim Graham <james.graham at oracle.com>:

> Is that on Sierpinski?  The main question I still have is whether this
> helps other apps.  The usage pattern in Sierpinski is fairly specific and
> may not translate to all apps (we're still planning on doing this as it is
> an easy improvement that doesn't seem to have a down-side, but I don't want
> to break out any champagne if it is just this one benchmark)...
>
>                         ...jim
>
> On 4/16/15 12:58 PM, Johan Vos wrote:
>
>> Hi Jim,
>>
>> On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
>> Excellent work!
>>
>> - Johan
>>
>> 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>>
>>  Hi Chris,
>>>
>>> We identified a fairly localized optimization that we might be able to
>>> apply to enhance the performance of your Sierpinski program.  We don't
>>> have
>>> any figures yet on whether this will improve other
>>> applications/benchmarks
>>> that people have been discussing, but the improvements with your
>>> Sierpinski
>>> program are quite dramatic on a number of platforms and GPUs.
>>>
>>> This issue is now being tracked as: https://javafx-jira.kenai.com/
>>> browse/RT-40533
>>>
>>> If others could apply the indicated patch to an OpenJFX build and provide
>>> feedback on any improvements (or bugs!) that they see, that would help.
>>> In
>>> the meantime, we have a lot of testing to do to verify the correctness of
>>> the changes...
>>>
>>>                          ...jim
>>>
>>>
>>> On 4/8/15 9:25 AM, Chris Newland wrote:
>>>
>>>  Hi Jim,
>>>>
>>>> I'll post the verbose prism output from my iMac when I get home.
>>>>
>>>> Just tried this on my Linux workstation and the performance gap is the
>>>> same between es2 and sw so I don't think it's an OSX issue.
>>>>
>>>> uname -a
>>>> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>>>>
>>>> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
>>>> com.chrisnewland.demofx.standalone.Sierpinski
>>>> fps: 1
>>>> fps: 20
>>>> fps: 31
>>>> fps: 32
>>>> fps: 33
>>>> fps: 35
>>>> fps: 34
>>>> fps: 33
>>>>
>>>> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
>>>> com.chrisnewland.demofx.standalone.Sierpinski
>>>> fps: 1
>>>> fps: 54
>>>> fps: 56
>>>> fps: 60
>>>> fps: 59
>>>> fps: 60
>>>> fps: 61
>>>> fps: 61
>>>> fps: 60
>>>>
>>>> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
>>>> graphics card running driver 304.125
>>>>
>>>> Regards,
>>>>
>>>> Chris
>>>>
>>>>
>>>> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>>>>
>>>>  OK, I took the time to put my rMBP on a diet yesterday and find room to
>>>>> install a 10.10 partition.  I get the same numbers for Sierpinski on
>>>>> 10.10,
>>>>> so my theory that something changed in the OGL implementation for 10.10
>>>>> doesn't hold water.
>>>>>
>>>>> But, I then tried it using the integrated graphics.  I get really poor
>>>>> performance using the integrated Intel 4000 graphics, but I get great
>>>>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>>>>> graphics wouldn't be as powerful as the discrete graphics, but we
>>>>> shouldn't be taxing it that much to make that big of a difference.
>>>>>
>>>>> Just to be sure - is that iMac a dual graphics system, or is it
>>>>> all-AMD-all-the-time?  You can see which GPU is being used if you run
>>>>> it
>>>>> with -Dprism.verbose=true...
>>>>>
>>>>> ...jim
>>>>>
>>>>>
>>>>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>>>>
>>>>>   On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are
>>>>> you
>>>>>
>>>>>> running a newer version of MacOS?
>>>>>>
>>>>>> ...jim
>>>>>>
>>>>>>
>>>>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>>>>
>>>>>>   Hi Herv?,
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That's a valid question :)
>>>>>>>
>>>>>>>
>>>>>>> Probably because
>>>>>>>
>>>>>>>
>>>>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>>>>> systems
>>>>>>>
>>>>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>>>>> to go for that due to the very large number of nodes.
>>>>>>>
>>>>>>> Numbers for my Sierpinski filled triangle example:
>>>>>>>
>>>>>>>
>>>>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>>>>> 1024 MB
>>>>>>>
>>>>>>>
>>>>>>> java -Dprism.order=es2 -cp target/classes/
>>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>>> fps: 23
>>>>>>> fps: 18
>>>>>>> fps: 25
>>>>>>> fps: 18
>>>>>>> fps: 23
>>>>>>> fps: 23
>>>>>>> fps: 19
>>>>>>> fps: 25
>>>>>>>
>>>>>>>
>>>>>>> java -Dprism.order=sw -cp target/classes/
>>>>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>>>>> fps: 54
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>> fps: 60
>>>>>>>
>>>>>>>
>>>>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>>>>> 1.8.0_40
>>>>>>>
>>>>>>>
>>>>>>> I would say there is a performance problem here? (or at least a need
>>>>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, March 31, 2015 22:00, Herv?? Girod wrote:
>>>>>>>
>>>>>>>   Why don't you use Nodes rather than Canvas ?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   On Mar 31, 2015, at 22:31, Chris Newland
>>>>>>>>
>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, that makes things much clearer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I was surprised how much was going on under the hood of
>>>>>>>>> GraphicsContext
>>>>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>>>>> acceleration where available and immediate-mode-like simple
>>>>>>>>> rasterizing where not.
>>>>>>>>>
>>>>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>>>>> so I expect suffers from the problem you've described.
>>>>>>>>>
>>>>>>>>> SSCCE:
>>>>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>>>>> com/ch
>>>>>>>>>
>>>>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>>>>
>>>>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>>>>> JavaFX or
>>>>>>>>> would I be better off with Graphics2D?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>>>>> with a GPU
>>>>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>>>>> with an appropriate shader which is very fast.
>>>>>>>>>>
>>>>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>>>>> like:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>>>>    drawLine() - dealing with only rendering common points of
>>>>>>>>>> intersection once
>>>>>>>>>>
>>>>>>>>>> To handle all of that complexity we have to involve a
>>>>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>>>>> currently for all pipelines.
>>>>>>>>>>
>>>>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>>>>> CPU path
>>>>>>>>>> rasterization.
>>>>>>>>>>
>>>>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>>>>> dominates its performance.
>>>>>>>>>>
>>>>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>>>>
>>>>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>>>>> case. Does
>>>>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>>>>> SW
>>>>>>>>>> pipeline for the polygon case?
>>>>>>>>>>
>>>>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>>>>> calls faster than drawPolygon as well...
>>>>>>>>>>
>>>>>>>>>> ...jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>>>>> I'd
>>>>>>>>>>> better add my findings.
>>>>>>>>>>>
>>>>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>>>>> strokeLine commands as expected:
>>>>>>>>>>>
>>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>>>>> Result:
>>>>>>>>>>> 44fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>>>>> Result:
>>>>>>>>>>> 60fps
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>>>>    examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>>>>
>>>>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>>>>> JavaFX
>>>>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>>>>> do think there's a bug here.
>>>>>>>>>>>
>>>>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>>>>> slow" ;)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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(Op
>>>>>>>>>>>> en%2C% 20%2
>>>>>>>>>>>> 2In%
>>>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>>>>> 20%20A
>>>>>>>>>>>> ND%2
>>>>>>>>>>>> 0la
>>>>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>>>>
>>>>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>>>>> least OSX and Windows and
>>>>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>>>>
>>>>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>>>>> across diverse platforms"
>>>>>>>>>>>>
>>>>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>>>>> (8u40)
>>>>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>>>>    performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>>>>
>>>>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>>>>> performance that can be tracked?
>>>>>>>>>>>>
>>>>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>>>>> the best.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   Possibly related:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>>>>> count) command.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Build with ant
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Run with:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> # use strokeLine
>>>>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> # use strokePolygon
>>>>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>>>>> 20GB RAM
>>>>>>>>>>>>> /
>>>>>>>>>>>>> Radeon
>>>>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking at the code paths in
>>>>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>>>>> than using the convenience method.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>>>>
>>>>>>>>>>>>>> isn????????t good at all with JavaFX???????.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Am 27.03.2015 um 22:10 schrieb Robert Kr????ger
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Hi Robert,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>>>>    predetermined shader, but it shouldn't be that
>>>>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Kr????ger wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>>>>    AnimationTimer
>>>>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>>>>    serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Robert Kr????ger
>>>>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Robert Kr??ger
>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>

From felix.bembrick at gmail.com  Mon Apr 20 11:15:47 2015
From: felix.bembrick at gmail.com (Felix Bembrick)
Date: Mon, 20 Apr 2015 21:15:47 +1000
Subject: Enhancements to 3D for JFX9?
Message-ID: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>

As awesome as JavaFX is right now, for me it's greatest weakness especially when compared to competing products is it's extremely rudimentary support for 3D graphics. Even the old Java3D was considerably more advanced.

Is beefing up 3D support in JFX9 seen as a priority and if so what features are being considered?

I am not expecting a full-on rival for Unity3D but I am hoping to be able to build complex 3D games and scientific visualisations using custom shaders etc. and support for WebGL not just within WebKit itself but in a stand alone 3D Canvas node with full and extra 3D features.

Of course all of this must work not just on the desktop but also on mobile platforms and embedded where feasible. 

Am I dreaming?

Felix

From danno.ferrin at oracle.com  Mon Apr 20 17:56:42 2015
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 20 Apr 2015 11:56:42 -0600
Subject: RT-40554: On Mac, application created by javapackager can not run.
Message-ID: <998B0EEF-9572-4BDE-B54D-24138D164001@oracle.com>

Kevin, Chris
Please review for inclusion in b12

webrev: http://cr.openjdk.java.net/~shemnon/RT-40554/webrev.01/ <http://cr.openjdk.java.net/~shemnon/RT-40554/webrev.01/>
Bug: RT-40554: On Mac, application created by javapackager can not run.

From leif.samuelsson at oracle.com  Mon Apr 20 19:24:21 2015
From: leif.samuelsson at oracle.com (Leif Samuelsson)
Date: Mon, 20 Apr 2015 12:24:21 -0700
Subject: [8u60,9] Review request: RT-39464: Polytonic displays incorrectly
	when typed in (via TextField)
Message-ID: <55355265.5030008@oracle.com>

Hi Chien and Kevin,

Please review this fix for Glass on Windows.

   https://javafx-jira.kenai.com/browse/RT-39464
   http://cr.openjdk.java.net/~leifs/rt39464/webrev.01/

Thanks,
Leif

From jeffhain at rocketmail.com  Mon Apr 20 19:46:18 2015
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Mon, 20 Apr 2015 19:46:18 +0000 (UTC)
Subject: Font size, dpi and text crispness (snapping to pixels)
In-Reply-To: <B10C4519-8337-47FE-B5CE-AE4FF2AC0EBB@reportmill.com>
References: <B10C4519-8337-47FE-B5CE-AE4FF2AC0EBB@reportmill.com>
Message-ID: <1004425374.1035533.1429559178916.JavaMail.yahoo@mail.yahoo.com>


Matthieu BROUILLARD wrote :>myText.setFontSmoothingType(FontSmoothingType.LCD)

Tried it, but it didn't give consistent results across 90 degrees rotations (using GraphicsContext.transform(...)),i.e. text for 90 and 270 degrees is in some places quite thicker (well, quite = 1 pixel, but easy to see)than text for 0 and 180, whereas with FontSmoothingType.GRAY (the default) text remains quite alikeacross all these rotations.
(was using Lucida Console, size 20)


-Jeff

 

From kevin.rushforth at oracle.com  Mon Apr 20 20:18:00 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 20 Apr 2015 13:18:00 -0700
Subject: 8u-dev and 9-dev unlocked following sanity testing <eom>
Message-ID: <55355EF8.1020004@oracle.com>



From tbee at tbee.org  Tue Apr 21 07:52:32 2015
From: tbee at tbee.org (Tom Eugelink)
Date: Tue, 21 Apr 2015 09:52:32 +0200
Subject: Off topic: named parameters
Message-ID: <553601C0.2010207@tbee.org>

Totally off topic, I apologise, but the subscribers to this list are the type of people who may have the experience I seek.

I've been trying to pitch the concept of named parameters for Java 9, but somehow my JEP is never picked up. I emailed it in twice. Has anyone ever successfully handed in a JEP?
https://tbeernot.wordpress.com/2013/09/29/the-java-9-named-parameter-pitch/

Tom

From ooo_saturn7 at mail.ru  Tue Apr 21 08:46:12 2015
From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=)
Date: Tue, 21 Apr 2015 11:46:12 +0300
Subject: =?UTF-8?B?UmU6IG9wZW5qZngtZGV2IERpZ2VzdCwgVm9sIDQxLCBJc3N1ZSAzMA==?=
In-Reply-To: <mailman.60524.1429557865.10816.openjfx-dev@openjdk.java.net>
References: <mailman.60524.1429557865.10816.openjfx-dev@openjdk.java.net>
Message-ID: <1429605972.754777909@f264.i.mail.ru>

 I am trying to build openjfx from sources - centos 6.4. 64 openjdk8 (build 25.60-b11, mixed mode), I run 

/gradle-1.8/bin/gradle --info --debug

and this is what I get:
10:11:09.184 [ERROR] [system.err] cc1plus: warnings being treated as errors
10:11:09.186 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:114: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
10:11:09.187 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:132: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
10:11:09.187 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED
10:11:09.188 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'gcc'' finished with exit value 1 (state: FAILED)
10:11:09.195 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer at 675d3402, org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 51565ec2, org.gradle.logging.internal.JavaUtilLoggingConfigurer at 482f8f11]
10:11:09.195 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:ccLinuxGlass'
10:11:09.195 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:ccLinuxGlass FAILED
10:11:09.196 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:ccLinuxGlass (Thread[main,5,main]) completed. Took 1.1 secs.
10:11:09.196 [DEBUG] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker [Thread[main,5,main]] finished, busy: 5.129 secs, idle: 0.044 secs
10:11:09.212 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.216 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception.
10:11:09.217 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.220 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:
10:11:09.221 [ERROR] [org.gradle.BuildExceptionReporter] Execution failed for task ':graphics:ccLinuxGlass'.
10:11:09.222 [ERROR] [org.gradle.BuildExceptionReporter] > Could not call NativeCompileTask.compile() on task ':graphics:ccLinuxGlass'
10:11:09.225 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.226 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is:
10:11:09.231 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':graphics:ccLinuxGlass'.
10:11:09.232 [ERROR] [org.gradle.BuildExceptionReporter] ?? ?at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)

how to solve it?





From ooo_saturn7 at mail.ru  Tue Apr 21 08:48:13 2015
From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=)
Date: Tue, 21 Apr 2015 11:48:13 +0300
Subject: =?UTF-8?B?RXJyb3JzIHdoaWxlIGJ1aWxkaW5nIG9wZW5qZnggZnJvbSBzb3VyY2Vz?=
In-Reply-To: <mailman.60524.1429557865.10816.openjfx-dev@openjdk.java.net>
References: <mailman.60524.1429557865.10816.openjfx-dev@openjdk.java.net>
Message-ID: <1429606093.138838466@f264.i.mail.ru>

 I am trying to build openjfx from sources - centos 6.4. 64 openjdk8 (build 25.60-b11, mixed mode), I run 

/gradle-1.8/bin/gradle --info --debug

and this is what I get:
10:11:09.184 [ERROR] [system.err] cc1plus: warnings being treated as errors
10:11:09.186 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:114: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
10:11:09.187 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:132: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
10:11:09.187 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED
10:11:09.188 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'gcc'' finished with exit value 1 (state: FAILED)
10:11:09.195 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer at 675d3402, org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 51565ec2, org.gradle.logging.internal.JavaUtilLoggingConfigurer at 482f8f11]
10:11:09.195 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:ccLinuxGlass'
10:11:09.195 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:ccLinuxGlass FAILED
10:11:09.196 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:ccLinuxGlass (Thread[main,5,main]) completed. Took 1.1 secs.
10:11:09.196 [DEBUG] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker [Thread[main,5,main]] finished, busy: 5.129 secs, idle: 0.044 secs
10:11:09.212 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.216 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception.
10:11:09.217 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.220 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:
10:11:09.221 [ERROR] [org.gradle.BuildExceptionReporter] Execution failed for task ':graphics:ccLinuxGlass'.
10:11:09.222 [ERROR] [org.gradle.BuildExceptionReporter] > Could not call NativeCompileTask.compile() on task ':graphics:ccLinuxGlass'
10:11:09.225 [ERROR] [org.gradle.BuildExceptionReporter] 
10:11:09.226 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is:
10:11:09.231 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':graphics:ccLinuxGlass'.
10:11:09.232 [ERROR] [org.gradle.BuildExceptionReporter] ?? ?at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)

how to solve it?

From alexander.zvegintsev at oracle.com  Tue Apr 21 09:52:07 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 21 Apr 2015 12:52:07 +0300
Subject: Errors while building openjfx from sources
In-Reply-To: <1429606093.138838466@f264.i.mail.ru>
References: <mailman.60524.1429557865.10816.openjfx-dev@openjdk.java.net>
	<1429606093.138838466@f264.i.mail.ru>
Message-ID: <55361DC7.5060805@oracle.com>

Hello Alexander,

It looks like that you have GCC version < 4.6 and it lacks diagnostics 
push/pop functionality[1]
that we are using to suppress deprecation warnings. We have moved to gcc 
4.8 on Linux recently[2].

So the fix is to upgrade GCC to at least 4.6. Or as a workaround you may 
apply following patch:

diff -r 8b7ea03165e9 buildSrc/linux.gradle
--- a/buildSrc/linux.gradle
+++ b/buildSrc/linux.gradle
@@ -138,7 +138,7 @@ LINUX.glass.javahInclude = [
      "com/sun/glass/ui/gtk/*"]
  LINUX.glass.nativeSource = 
file("modules/graphics/src/main/native-glass/gtk")
  LINUX.glass.compiler = compiler
-LINUX.glass.ccFlags = [ccFlags, "-Werror"].flatten()
+LINUX.glass.ccFlags = ccFlags
  LINUX.glass.linker = linker
  LINUX.glass.linkFlags = [linkFlags].flatten()
  LINUX.glass.lib = "glass"

It stops treating warning as errors[3].

[1] https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-March/016911.html
[3] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Thanks,

Alexander.

On 04/21/2015 11:48 AM, ????????? ???????? wrote:
>   I am trying to build openjfx from sources - centos 6.4. 64 openjdk8 (build 25.60-b11, mixed mode), I run
>
> /gradle-1.8/bin/gradle --info --debug
>
> and this is what I get:
> 10:11:09.184 [ERROR] [system.err] cc1plus: warnings being treated as errors
> 10:11:09.186 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:114: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
> 10:11:09.187 [ERROR] [system.err] /home/PE/Temp/rt/modules/graphics/src/main/native-glass/gtk/glass_general.cpp:132: error: expected [error|warning|ignored] after '#pragma GCC diagnostic'
> 10:11:09.187 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED
> 10:11:09.188 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'gcc'' finished with exit value 1 (state: FAILED)
> 10:11:09.195 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer at 675d3402, org.gradle.logging.internal.logback.LogbackLoggingConfigurer at 51565ec2, org.gradle.logging.internal.JavaUtilLoggingConfigurer at 482f8f11]
> 10:11:09.195 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:ccLinuxGlass'
> 10:11:09.195 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :graphics:ccLinuxGlass FAILED
> 10:11:09.196 [INFO] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] :graphics:ccLinuxGlass (Thread[main,5,main]) completed. Took 1.1 secs.
> 10:11:09.196 [DEBUG] [org.gradle.execution.taskgraph.AbstractTaskPlanExecutor] Task worker [Thread[main,5,main]] finished, busy: 5.129 secs, idle: 0.044 secs
> 10:11:09.212 [ERROR] [org.gradle.BuildExceptionReporter]
> 10:11:09.216 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception.
> 10:11:09.217 [ERROR] [org.gradle.BuildExceptionReporter]
> 10:11:09.220 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong:
> 10:11:09.221 [ERROR] [org.gradle.BuildExceptionReporter] Execution failed for task ':graphics:ccLinuxGlass'.
> 10:11:09.222 [ERROR] [org.gradle.BuildExceptionReporter] > Could not call NativeCompileTask.compile() on task ':graphics:ccLinuxGlass'
> 10:11:09.225 [ERROR] [org.gradle.BuildExceptionReporter]
> 10:11:09.226 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is:
> 10:11:09.231 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':graphics:ccLinuxGlass'.
> 10:11:09.232 [ERROR] [org.gradle.BuildExceptionReporter]     at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
>
> how to solve it?


From mike at plan99.net  Tue Apr 21 10:59:34 2015
From: mike at plan99.net (Mike Hearn)
Date: Tue, 21 Apr 2015 12:59:34 +0200
Subject: Off topic: named parameters
In-Reply-To: <553601C0.2010207@tbee.org>
References: <553601C0.2010207@tbee.org>
Message-ID: <CANEZrP0hsmCvjKvBoCMbPMorVNJJMSRo01O2YenWio1OgD7o+Q@mail.gmail.com>

I don't know about JEP submission process, but you'd first have to solve
the problem that when Java added serialization of parameter names to class
files in Java 8, the OpenJDK devs explicitly decided *not* to expose them
for the JDK itself, on the grounds that they didn't want parameter names to
become part of the API. That's why you have to pass -parameters to javac to
get the new feature.

Adding named parameters to the Java language is probably a fair bit of
work. You'd need to build consensus for it on the relevant mailing lists
and with the relevant people first, before even getting to the JEP stage I
guess. An easier path: figure out how to get parameter names as part of the
JDK API and then work with the JetBrains Kotlin team. Kotlin is a very very
Java compatible JVM language, and it already supports named parameters by
default so they don't have the same hangups about the API compatibility
aspect. The Kotlin compiler routinely uses annotation data from Java
classes already so that's not a big leap either.

I suspect what it will take to get the JDK folks happy with exporting
parameter names by default is the ability to overload methods that differ
only by parameter names, so if you have a method with bad names then you
can add an overload with good names. However this would require a (much
smaller) change to the Java language, changes to javac, changes to how the
JVM does method linkage (possibly?) and so on.

Another possible plan of attack would be to calculate API diffs over time
and measure how often parameter names are actually changed. My guess is
"not often". If you can prove that they're worried about a relatively
uncommon problem then perhaps the JDK maintainers can be convinced to make
parameter names a part of the API, perhaps after an API cleanup pass to
find obviously bogus names and fix them.

Alternatively, given that Java is open source, you can of course go ahead
and make your own version of the JRE that exports this data by default.
Then you accept the possibility of upstream breaking your code and just
swallow it.

On Tue, Apr 21, 2015 at 9:52 AM, Tom Eugelink <tbee at tbee.org> wrote:

> Totally off topic, I apologise, but the subscribers to this list are the
> type of people who may have the experience I seek.
>
> I've been trying to pitch the concept of named parameters for Java 9, but
> somehow my JEP is never picked up. I emailed it in twice. Has anyone ever
> successfully handed in a JEP?
> https://tbeernot.wordpress.com/2013/09/29/the-java-9-named-parameter-pitch/
>
> Tom
>

From ooo_saturn7 at mail.ru  Tue Apr 21 11:34:37 2015
From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=)
Date: Tue, 21 Apr 2015 14:34:37 +0300
Subject: =?UTF-8?B?SmF2YUZYOiBDYW4ndCBsb2FkIGxpYnJhcnk6IGxpYmpmeHdlYmtpdC5zbw==?=
In-Reply-To: <mailman.60676.1429613976.10816.openjfx-dev@openjdk.java.net>
References: <mailman.60676.1429613976.10816.openjfx-dev@openjdk.java.net>
Message-ID: <1429616077.37591676@f337.i.mail.ru>


I use centos 6.4 + openjdk8 (build 25.40-b18, mixed mode) and openjfx (I build it from today sources).
I have 64 box. And I can't use the html components (all other components seem to work normally) - webview,webengine,htmleditor. When I try to use them I get:
Caused by: java.lang.UnsatisfiedLinkError:Can't load library:/usr/java/j2sdk-image/jre/lib/amd64/libjfxwebkit.so
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1083)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoader.java:201)
    at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:94)
    at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:39)
    at com.sun.webkit.WebPage.lambda$static$38(WebPage.java:127)
    at com.sun.webkit.WebPage$$Lambda$70/1840187125.run(UnknownSource)
    at java.security.AccessController.doPrivileged(NativeMethod)
    at com.sun.webkit.WebPage.<clinit>(WebPage.java:126)
    at javafx.scene.web.WebEngine.<init>(WebEngine.java:824)
I tried to find this lib on my PC but didn't find. I tried to find in repos:
yum provides libjfxwebkit.so
but also didn't find. What should I do?

From kevin.rushforth at oracle.com  Tue Apr 21 14:57:12 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 21 Apr 2015 07:57:12 -0700
Subject: JavaFX: Can't load library: libjfxwebkit.so
In-Reply-To: <1429616077.37591676@f337.i.mail.ru>
References: <mailman.60676.1429613976.10816.openjfx-dev@openjdk.java.net>
	<1429616077.37591676@f337.i.mail.ru>
Message-ID: <55366548.5000904@oracle.com>

When you build OpenJFX it doesn't build the media or webkit libraries by 
default. You can enable them, but they (especially WebKit) require 
additional libraries on your build machine. If you don't build them, it 
will use the ones from the JDK that you use to build. The ones we 
currently ship with 8u60 (and 9) early access don't work on older Linux 
distros.

See https://javafx-jira.kenai.com/browse/RT-40550

-- Kevin


????????? ???????? wrote:
> I use centos 6.4 + openjdk8 (build 25.40-b18, mixed mode) and openjfx (I build it from today sources).
> I have 64 box. And I can't use the html components (all other components seem to work normally) - webview,webengine,htmleditor. When I try to use them I get:
> Caused by: java.lang.UnsatisfiedLinkError:Can't load library:/usr/java/j2sdk-image/jre/lib/amd64/libjfxwebkit.so
>     at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
>     at java.lang.Runtime.load0(Runtime.java:809)
>     at java.lang.System.load(System.java:1083)
>     at com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoader.java:201)
>     at com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:94)
>     at com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:39)
>     at com.sun.webkit.WebPage.lambda$static$38(WebPage.java:127)
>     at com.sun.webkit.WebPage$$Lambda$70/1840187125.run(UnknownSource)
>     at java.security.AccessController.doPrivileged(NativeMethod)
>     at com.sun.webkit.WebPage.<clinit>(WebPage.java:126)
>     at javafx.scene.web.WebEngine.<init>(WebEngine.java:824)
> I tried to find this lib on my PC but didn't find. I tried to find in repos:
> yum provides libjfxwebkit.so
> but also didn't find. What should I do?

From herve.girod at gmail.com  Tue Apr 21 22:59:56 2015
From: herve.girod at gmail.com (Herve Girod)
Date: Wed, 22 Apr 2015 00:59:56 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
Message-ID: <CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>

Hello,

As a newbie user of Java 3D, I have some suggestions in the back of my head
for Java 9, as for example:
- managing opacity (alpha) on 3D Node (the most important IMO)
- parallel lights
- managing far / near clip with parallel camera
- some more built-in 3D Shapes would be useful

I think that most, if not all, of these are already filed in JIRA.

Herv?

2015-04-20 13:15 GMT+02:00 Felix Bembrick <felix.bembrick at gmail.com>:

> As awesome as JavaFX is right now, for me it's greatest weakness
> especially when compared to competing products is it's extremely
> rudimentary support for 3D graphics. Even the old Java3D was considerably
> more advanced.
>
> Is beefing up 3D support in JFX9 seen as a priority and if so what
> features are being considered?
>
> I am not expecting a full-on rival for Unity3D but I am hoping to be able
> to build complex 3D games and scientific visualisations using custom
> shaders etc. and support for WebGL not just within WebKit itself but in a
> stand alone 3D Canvas node with full and extra 3D features.
>
> Of course all of this must work not just on the desktop but also on mobile
> platforms and embedded where feasible.
>
> Am I dreaming?
>
> Felix

From chien.yang at oracle.com  Wed Apr 22 01:30:21 2015
From: chien.yang at oracle.com (Chien Yang)
Date: Tue, 21 Apr 2015 18:30:21 -0700
Subject: Code Review Request For RT-40004: [3D] Texture transparency is ignored
	in 8u40
Message-ID: <5536F9AD.7070809@oracle.com>

Hi Kevin,

Please review the proposed fix.

JiRA: https://javafx-jira.kenai.com/browse/RT-40004
Webrev: http://cr.openjdk.java.net/~ckyang/RT-40004/webrev.00/

Thanks,
- Chien

From kevin.rushforth at oracle.com  Wed Apr 22 01:37:16 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 21 Apr 2015 18:37:16 -0700
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
Message-ID: <5536FB4C.8000501@oracle.com>

Of these, handling transparency / blending is likely for JDK 9.

-- Kevin


Herve Girod wrote:
> Hello,
>
> As a newbie user of Java 3D, I have some suggestions in the back of my head
> for Java 9, as for example:
> - managing opacity (alpha) on 3D Node (the most important IMO)
> - parallel lights
> - managing far / near clip with parallel camera
> - some more built-in 3D Shapes would be useful
>
> I think that most, if not all, of these are already filed in JIRA.
>
> Herv?
>
> 2015-04-20 13:15 GMT+02:00 Felix Bembrick <felix.bembrick at gmail.com>:
>
>   
>> As awesome as JavaFX is right now, for me it's greatest weakness
>> especially when compared to competing products is it's extremely
>> rudimentary support for 3D graphics. Even the old Java3D was considerably
>> more advanced.
>>
>> Is beefing up 3D support in JFX9 seen as a priority and if so what
>> features are being considered?
>>
>> I am not expecting a full-on rival for Unity3D but I am hoping to be able
>> to build complex 3D games and scientific visualisations using custom
>> shaders etc. and support for WebGL not just within WebKit itself but in a
>> stand alone 3D Canvas node with full and extra 3D features.
>>
>> Of course all of this must work not just on the desktop but also on mobile
>> platforms and embedded where feasible.
>>
>> Am I dreaming?
>>
>> Felix
>>     

From felix.bembrick at gmail.com  Wed Apr 22 04:35:34 2015
From: felix.bembrick at gmail.com (Felix Bembrick)
Date: Wed, 22 Apr 2015 14:35:34 +1000
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <5536FB4C.8000501@oracle.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
Message-ID: <CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>

What about:

1) Custom shaders
2) 3D Canvas

Felix

On 22 April 2015 at 11:37, Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Of these, handling transparency / blending is likely for JDK 9.
>
> -- Kevin
>
>
>
> Herve Girod wrote:
>
>> Hello,
>>
>> As a newbie user of Java 3D, I have some suggestions in the back of my
>> head
>> for Java 9, as for example:
>> - managing opacity (alpha) on 3D Node (the most important IMO)
>> - parallel lights
>> - managing far / near clip with parallel camera
>> - some more built-in 3D Shapes would be useful
>>
>> I think that most, if not all, of these are already filed in JIRA.
>>
>> Herv?
>>
>> 2015-04-20 13:15 GMT+02:00 Felix Bembrick <felix.bembrick at gmail.com>:
>>
>>
>>
>>> As awesome as JavaFX is right now, for me it's greatest weakness
>>> especially when compared to competing products is it's extremely
>>> rudimentary support for 3D graphics. Even the old Java3D was considerably
>>> more advanced.
>>>
>>> Is beefing up 3D support in JFX9 seen as a priority and if so what
>>> features are being considered?
>>>
>>> I am not expecting a full-on rival for Unity3D but I am hoping to be able
>>> to build complex 3D games and scientific visualisations using custom
>>> shaders etc. and support for WebGL not just within WebKit itself but in a
>>> stand alone 3D Canvas node with full and extra 3D features.
>>>
>>> Of course all of this must work not just on the desktop but also on
>>> mobile
>>> platforms and embedded where feasible.
>>>
>>> Am I dreaming?
>>>
>>> Felix
>>>
>>>
>>

From anton.tarasov at oracle.com  Wed Apr 22 11:56:12 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 22 Apr 2015 14:56:12 +0300
Subject: [9] post-commit notification: RT-40605 [WebView] use OUT_PWD for
	a current build dir
Message-ID: <55378C5C.3060704@oracle.com>

JIRA: https://javafx-jira.kenai.com/browse/RT-40605
Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ce91d2419086

Regards,
Anton.

From anton.tarasov at oracle.com  Wed Apr 22 12:48:02 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 22 Apr 2015 15:48:02 +0300
Subject: [8u-dev] post-commit notification: RT-40608, RT-40560, RT-40605,
	RT-40561
Message-ID: <55379882.2060909@oracle.com>

Direct backports:

https://javafx-jira.kenai.com/browse/RT-40608
changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a589b750789f

https://javafx-jira.kenai.com/browse/RT-40560
changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4cf12ed74b40

https://javafx-jira.kenai.com/browse/RT-40605
changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ee7146b4ffc0

https://javafx-jira.kenai.com/browse/RT-40561
changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b88922e7b1e4

Regards,
Anton.

From vadim.pakhnushev at oracle.com  Wed Apr 22 14:14:23 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Wed, 22 Apr 2015 17:14:23 +0300
Subject: [8u60, 9] Review request for RT-40544: Updating BarChart data causes
	memory leak
Message-ID: <5537ACBF.6040404@oracle.com>

Jonathan,

Please review the fix:
https://javafx-jira.kenai.com/browse/RT-40544
http://cr.openjdk.java.net/~vadim/RT-40544/webrev.00/

Thanks,
Vadim

From felix.bembrick at gmail.com  Thu Apr 23 10:37:36 2015
From: felix.bembrick at gmail.com (Felix Bembrick)
Date: Thu, 23 Apr 2015 20:37:36 +1000
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
Message-ID: <76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>

Anyone?

Felix

> On 22 Apr 2015, at 14:35, Felix Bembrick <felix.bembrick at gmail.com> wrote:
> 
> What about:
> 
> 1) Custom shaders
> 2) 3D Canvas
> 
> Felix
> 
>> On 22 April 2015 at 11:37, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> Of these, handling transparency / blending is likely for JDK 9.
>> 
>> -- Kevin
>> 
>> 
>> 
>> Herve Girod wrote:
>>> Hello,
>>> 
>>> As a newbie user of Java 3D, I have some suggestions in the back of my head
>>> for Java 9, as for example:
>>> - managing opacity (alpha) on 3D Node (the most important IMO)
>>> - parallel lights
>>> - managing far / near clip with parallel camera
>>> - some more built-in 3D Shapes would be useful
>>> 
>>> I think that most, if not all, of these are already filed in JIRA.
>>> 
>>> Herv?
>>> 
>>> 2015-04-20 13:15 GMT+02:00 Felix Bembrick <felix.bembrick at gmail.com>:
>>> 
>>>   
>>>> As awesome as JavaFX is right now, for me it's greatest weakness
>>>> especially when compared to competing products is it's extremely
>>>> rudimentary support for 3D graphics. Even the old Java3D was considerably
>>>> more advanced.
>>>> 
>>>> Is beefing up 3D support in JFX9 seen as a priority and if so what
>>>> features are being considered?
>>>> 
>>>> I am not expecting a full-on rival for Unity3D but I am hoping to be able
>>>> to build complex 3D games and scientific visualisations using custom
>>>> shaders etc. and support for WebGL not just within WebKit itself but in a
>>>> stand alone 3D Canvas node with full and extra 3D features.
>>>> 
>>>> Of course all of this must work not just on the desktop but also on mobile
>>>> platforms and embedded where feasible.
>>>> 
>>>> Am I dreaming?
>>>> 
>>>> Felix
> 

From mike at plan99.net  Thu Apr 23 10:50:45 2015
From: mike at plan99.net (Mike Hearn)
Date: Thu, 23 Apr 2015 12:50:45 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
Message-ID: <CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>

Well, JavaFX is actually a GUI widget toolkit rather than a 3D graphics
engine. I think Kevin laid out what they plan to do for v9 so you can
assume that the other things won't get done unless you contribute the code
yourself.

I think there are people who are embedding arbitrary OpenGL contexts into
the JFX scene graph, so you could plug in a third party 3D engine that way.
Though I guess it'd not work on Windows.

On Thu, Apr 23, 2015 at 12:37 PM, Felix Bembrick <felix.bembrick at gmail.com>
wrote:

> Anyone?
>
> Felix
>
> > On 22 Apr 2015, at 14:35, Felix Bembrick <felix.bembrick at gmail.com>
> wrote:
> >
> > What about:
> >
> > 1) Custom shaders
> > 2) 3D Canvas
> >
> > Felix
> >
> >> On 22 April 2015 at 11:37, Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
> >> Of these, handling transparency / blending is likely for JDK 9.
> >>
> >> -- Kevin
> >>
> >>
> >>
> >> Herve Girod wrote:
> >>> Hello,
> >>>
> >>> As a newbie user of Java 3D, I have some suggestions in the back of my
> head
> >>> for Java 9, as for example:
> >>> - managing opacity (alpha) on 3D Node (the most important IMO)
> >>> - parallel lights
> >>> - managing far / near clip with parallel camera
> >>> - some more built-in 3D Shapes would be useful
> >>>
> >>> I think that most, if not all, of these are already filed in JIRA.
> >>>
> >>> Herv?
> >>>
> >>> 2015-04-20 13:15 GMT+02:00 Felix Bembrick <felix.bembrick at gmail.com>:
> >>>
> >>>
> >>>> As awesome as JavaFX is right now, for me it's greatest weakness
> >>>> especially when compared to competing products is it's extremely
> >>>> rudimentary support for 3D graphics. Even the old Java3D was
> considerably
> >>>> more advanced.
> >>>>
> >>>> Is beefing up 3D support in JFX9 seen as a priority and if so what
> >>>> features are being considered?
> >>>>
> >>>> I am not expecting a full-on rival for Unity3D but I am hoping to be
> able
> >>>> to build complex 3D games and scientific visualisations using custom
> >>>> shaders etc. and support for WebGL not just within WebKit itself but
> in a
> >>>> stand alone 3D Canvas node with full and extra 3D features.
> >>>>
> >>>> Of course all of this must work not just on the desktop but also on
> mobile
> >>>> platforms and embedded where feasible.
> >>>>
> >>>> Am I dreaming?
> >>>>
> >>>> Felix
> >
>

From kevin.rushforth at oracle.com  Thu Apr 23 12:33:36 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 23 Apr 2015 05:33:36 -0700
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
Message-ID: <5538E6A0.1080506@oracle.com>

These are not planned for 9. Custom shaders in particular would be a lot 
of work, and expose some real challenges to get right in a way that 
would interact well with the rest of the system.

The only 3D improvement currently on our radar is adding API for alpha 
blending, although we could consider minor Tweaks.

-- Kevin


Felix Bembrick wrote:
> Anyone?
>
> Felix
>
> On 22 Apr 2015, at 14:35, Felix Bembrick <felix.bembrick at gmail.com 
> <mailto:felix.bembrick at gmail.com>> wrote:
>
>> What about:
>>
>> 1) Custom shaders
>> 2) 3D Canvas
>>
>> Felix
>>
>> On 22 April 2015 at 11:37, Kevin Rushforth 
>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>
>>     Of these, handling transparency / blending is likely for JDK 9.
>>
>>     -- Kevin
>>
>>
>>
>>     Herve Girod wrote:
>>
>>         Hello,
>>
>>         As a newbie user of Java 3D, I have some suggestions in the
>>         back of my head
>>         for Java 9, as for example:
>>         - managing opacity (alpha) on 3D Node (the most important IMO)
>>         - parallel lights
>>         - managing far / near clip with parallel camera
>>         - some more built-in 3D Shapes would be useful
>>
>>         I think that most, if not all, of these are already filed in
>>         JIRA.
>>
>>         Herv?
>>
>>         2015-04-20 13:15 GMT+02:00 Felix Bembrick
>>         <felix.bembrick at gmail.com <mailto:felix.bembrick at gmail.com>>:
>>
>>          
>>
>>             As awesome as JavaFX is right now, for me it's greatest
>>             weakness
>>             especially when compared to competing products is it's
>>             extremely
>>             rudimentary support for 3D graphics. Even the old Java3D
>>             was considerably
>>             more advanced.
>>
>>             Is beefing up 3D support in JFX9 seen as a priority and
>>             if so what
>>             features are being considered?
>>
>>             I am not expecting a full-on rival for Unity3D but I am
>>             hoping to be able
>>             to build complex 3D games and scientific visualisations
>>             using custom
>>             shaders etc. and support for WebGL not just within WebKit
>>             itself but in a
>>             stand alone 3D Canvas node with full and extra 3D features.
>>
>>             Of course all of this must work not just on the desktop
>>             but also on mobile
>>             platforms and embedded where feasible.
>>
>>             Am I dreaming?
>>
>>             Felix
>>                
>>
>>

From krueger at lesspain.de  Thu Apr 23 17:04:01 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Thu, 23 Apr 2015 19:04:01 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
Message-ID: <CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>

On Thu, Apr 23, 2015 at 12:50 PM, Mike Hearn <mike at plan99.net> wrote:

>
> I think there are people who are embedding arbitrary OpenGL contexts into
> the JFX scene graph, so you could plug in a third party 3D engine that way.
> Though I guess it'd not work on Windows.
>

since the fix version of RT-36215 was changed from 9 to tbd_major (?) and
given the fact that this currently only works using private API, depending
on if there will be a way to prevent the JRE from enforcing access
restrictions (see separate thread a few days ago), this may mean, people
who do this must work with a patched JDK in the future.

From leif.samuelsson at oracle.com  Thu Apr 23 20:07:43 2015
From: leif.samuelsson at oracle.com (Leif Samuelsson)
Date: Thu, 23 Apr 2015 13:07:43 -0700
Subject: [8u60,9] Review request: RT-39804: Apostrophe as dead key doesn't
	work on Windows 8.1 Latvian (Standard) keyboard layout
Message-ID: <5539510F.2060908@oracle.com>

Chien, Kevin, David,

Please review this fix for Glass on Windows.

   https://javafx-jira.kenai.com/browse/RT-39804
   http://cr.openjdk.java.net/~leifs/rt39804/webrev.01/

Thanks,
Leif

From adam at adamish.com  Fri Apr 24 08:30:33 2015
From: adam at adamish.com (Adam Granger)
Date: Fri, 24 Apr 2015 07:30:33 -0100
Subject: JavaFX always choose monospace font - possible bug?
Message-ID: <4b1b79d1ad114cdfcbc8ef347f50e0ae.squirrel@webmail.adamish.com>

I'm using a redhat 6 system with jdk 1.8u40 where the only font available
is "Liberation" in all its variants, bold, italic, mono, serif, sans-serif
etc.

/usr/share/fonts/liberation
/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
/usr/share/fonts/liberation/fonts.dir
/usr/share/fonts/liberation/LiberationMono-Italic.ttf
/usr/share/fonts/liberation/LiberationSans-Bold.ttf
/usr/share/fonts/liberation/LiberationSerif-Bold.ttf
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
/usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf
/usr/share/fonts/liberation/fonts.scale
/usr/share/fonts/liberation/LiberationSans-Regular.ttf
/usr/share/fonts/liberation/LiberationSans-Italic.ttf
/usr/share/fonts/liberation/LiberationMono-Bold.ttf

When I run up a app, even without custom CSS, all the controls,
textfields, buttons etc are displayed in monospaced liberation.

I've debugged this using -Dprism.debugFonts

Loading FontFactory com.sun.javafx.font.freetype.FTFactory
Subpixel: enabled
Freetype2 Loaded (version 2.3.11)
LCD support Enabled
Time spent accessing fontconfig=4ms.
FC font sans:regular:roman maps to Liberation Mono in file
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font sans:bold:roman maps to Liberation Mono Bold in file
/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font sans:regular:italic maps to Liberation Mono Italic in file
/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC font sans:bold:italic maps to Liberation Sans Bold Italic in file
/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
Bold Italic,
File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
Bold Italic,
File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC font serif:regular:roman maps to Liberation Mono in file
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font serif:bold:roman maps to Liberation Mono Bold in file
/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font serif:regular:italic maps to Liberation Mono Italic in file
/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC font serif:bold:italic maps to Liberation Sans Bold Italic in file
/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
Bold Italic,
File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
Bold Italic,
File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC font monospace:regular:roman maps to Liberation Mono in file
/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
 1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font monospace:bold:roman maps to Liberation Mono Bold in file
/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
 1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
 2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
FC font monospace:regular:italic maps to Liberation Mono Italic in file
/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
 1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC font monospace:bold:italic maps to Liberation Sans Bold Italic in file
/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
Bold Italic,
File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
 1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
Bold Italic,
File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
 2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
FC name=sans style=0 uses Liberation Mono in file:
/usr/share/fonts/liberation/LiberationMono-Regular.ttf

It seems that JavaFX makes mappings which I believe to be incorrect, for
example "sans:regular:roman" maps to Liberation Mono rather than
LiberationSans-Regular.

Firstly can anyone explain the 1) 2) 3) output that -Dprism.debugFonts
gives. What does this mean??

Secondly, is this a bug or not? Can anyone advise? Surely JavaFX should
map the logical font to it's "physical" equivalent, i.e. sans regular =>
<font name> sans regular, mono bold => <font name> mono bold etc.

I've read over https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup
but this doesn't help to explain this situation. I saw support for private
font font directory with -Dprism.fontdir however I'd prefer for JavaFX to
map to existing fonts in /usr/shar/fonts "correctly"

I also wrote this up at
http://stackoverflow.com/questions/29828681/javafx-uses-monospaced-font-for-all-controls
also, but had zero interest.

Regards,

Adam.






From mike at plan99.net  Fri Apr 24 11:16:31 2015
From: mike at plan99.net (Mike Hearn)
Date: Fri, 24 Apr 2015 13:16:31 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
Message-ID: <CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>

>
> this may mean, people who do this must work with a patched JDK in the
> future.
>

Right. But I think that's going to be more and more common in future. If
you rely on people installing proprietary stuff like JWS or applets then
it's a bleak future, as the way forward is clearly bundled JREs.

At some point I suspect someone will make a kind of "WebStart Next
Generation" without Oracle and start distributing a custom build of OpenJDK
+ their own platform/distribution stuff.

For example, a JRE that updates itself via Omaha on Windows would clearly
be superior to Oracle's solution:

   https://code.google.com/p/omaha

Combined with a more modern app store like approach rather than JNLP or
applets and that'd be a winner, I think.

From krueger at lesspain.de  Fri Apr 24 12:05:34 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 24 Apr 2015 14:05:34 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
Message-ID: <CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>

On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn <mike at plan99.net> wrote:

> this may mean, people who do this must work with a patched JDK in the
>> future.
>>
>
> Right. But I think that's going to be more and more common in future. If
> you rely on people installing proprietary stuff like JWS or applets then
> it's a bleak future, as the way forward is clearly bundled JREs.
>
>
>
patched != bundled. For us this would be quite a step back, having to
maintain our JDK patches/builds. Bundling itself is fine in our business
cases.

From tom.schindl at bestsolution.at  Fri Apr 24 12:19:32 2015
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 24 Apr 2015 14:19:32 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>	<5536FB4C.8000501@oracle.com>	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
Message-ID: <553A34D4.70405@bestsolution.at>

Did you read the reply from Phil in the other thread?

> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the transition. 

So you will not have to maintain a JDK9 build but only start with this
thread to still access private APIs and this is something you can
clearly control if you install the JDK with your app!

Tom

On 24.04.15 14:05, Robert Kr?ger wrote:
> On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn <mike at plan99.net> wrote:
> 
>> this may mean, people who do this must work with a patched JDK in the
>>> future.
>>>
>>
>> Right. But I think that's going to be more and more common in future. If
>> you rely on people installing proprietary stuff like JWS or applets then
>> it's a bleak future, as the way forward is clearly bundled JREs.
>>
>>
>>
> patched != bundled. For us this would be quite a step back, having to
> maintain our JDK patches/builds. Bundling itself is fine in our business
> cases.
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From krueger at lesspain.de  Fri Apr 24 13:35:17 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 24 Apr 2015 15:35:17 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <553A34D4.70405@bestsolution.at>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
	<553A34D4.70405@bestsolution.at>
Message-ID: <CAEnqZEX61ypXwHRriQ2a3Xuze7E45p7P16Dn0Qtqw_kZyywJoA@mail.gmail.com>

On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> Did you read the reply from Phil in the other thread?
>
> > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> transition.


> So you will not have to maintain a JDK9 build but only start with this
> thread to still access private APIs and this is something you can
> clearly control if you install the JDK with your app!
>

Excellent news! How could I miss that, sorry.

From donald.smith at oracle.com  Fri Apr 24 15:27:48 2015
From: donald.smith at oracle.com (Donald Smith)
Date: Fri, 24 Apr 2015 11:27:48 -0400
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <553A34D4.70405@bestsolution.at>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>	<5536FB4C.8000501@oracle.com>	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
	<553A34D4.70405@bestsolution.at>
Message-ID: <553A60F4.9040000@oracle.com>

Yes, but then read the rest of the thread.  You really must not rely on 
the theoretical possibility of an XX flag that magically kicks all your 
problems down the road a year or two.  The best time to get all this 
nailed correctly is now.  That flag is not likely to be as extensive and 
durable as everyone is imagining.

  - Don


On 24/04/2015 8:19 AM, Tom Schindl wrote:
> Did you read the reply from Phil in the other thread?
>
>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the transition.
> So you will not have to maintain a JDK9 build but only start with this
> thread to still access private APIs and this is something you can
> clearly control if you install the JDK with your app!
>
> Tom
>
> On 24.04.15 14:05, Robert Kr?ger wrote:
>> On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn <mike at plan99.net> wrote:
>>
>>> this may mean, people who do this must work with a patched JDK in the
>>>> future.
>>>>
>>> Right. But I think that's going to be more and more common in future. If
>>> you rely on people installing proprietary stuff like JWS or applets then
>>> it's a bleak future, as the way forward is clearly bundled JREs.
>>>
>>>
>>>
>> patched != bundled. For us this would be quite a step back, having to
>> maintain our JDK patches/builds. Bundling itself is fine in our business
>> cases.
>>
>


From krueger at lesspain.de  Fri Apr 24 15:53:53 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 24 Apr 2015 17:53:53 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <OF802B0827.D2EFED10-ON85257E31.005385D1-85257E31.0053CA80@abinitio.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
	<553A34D4.70405@bestsolution.at>
	<CAEnqZEX61ypXwHRriQ2a3Xuze7E45p7P16Dn0Qtqw_kZyywJoA@mail.gmail.com>
	<OF802B0827.D2EFED10-ON85257E31.005385D1-85257E31.0053CA80@abinitio.com>
Message-ID: <CAEnqZEUSf+dWd7esg=WMVuC2RCZ8XHVBkv1+nRH7iUTa4WGwQA@mail.gmail.com>

I agree and we are hesitant. However, if that buys you three or more years
of time to either see if Oracle is making good decisions regarding things
we now build using private APIs as a last resort or if all (for us)
showstopping JFX bugs are fixed by then, this can be a valid option in the
real world, where you have to deliver a product as opposed to now rushing
into a decision to move to a different technology, because Java/JFX cannot
deliver now but  YMMV. It's just balancing risks on a case-by-case basis.

People with complex, successful products like IntelliJ Idea are doing the
exact same thing:

https://github.com/JetBrains/intellij-community/search?utf8=%E2%9C%93&q=%22com.sun%22


On Fri, Apr 24, 2015 at 5:15 PM, <ngalarneau at abinitio.com> wrote:

> Of course, that flag could easily disappear in JDK10.
>
> Personally, I would be hesitant to rely on a feature that goes against the
> direction that Oracle is taking Java.
>
>
> Neil
>
>
>
>
> From:        Robert Kr?ger <krueger at lesspain.de>
> To:        "openjfx-dev at openjdk.java.net" <openjfx-dev at openjdk.java.net>,
> Date:        04/24/2015 09:36 AM
> Subject:        Re: Enhancements to 3D for JFX9?
> Sent by:        "openjfx-dev" <openjfx-dev-bounces at openjdk.java.net>
> ------------------------------
>
>
>
> On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
>
> > Did you read the reply from Phil in the other thread?
> >
> > > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> > transition.
>
>
> > So you will not have to maintain a JDK9 build but only start with this
> > thread to still access private APIs and this is something you can
> > clearly control if you install the JDK with your app!
> >
>
> Excellent news! How could I miss that, sorry.
>
>
>
>
> NOTICE *from Ab Initio: This email (including any attachments) may
> contain information that is subject to confidentiality obligations or is
> legally privileged, and sender does not waive confidentiality or privilege.
> If received in error, please notify the sender, delete this email, and make
> no further use, disclosure, or distribution. *




-- 
Robert Kr?ger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

From krueger at lesspain.de  Fri Apr 24 16:02:43 2015
From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=)
Date: Fri, 24 Apr 2015 18:02:43 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <553A60F4.9040000@oracle.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>
	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>
	<5536FB4C.8000501@oracle.com>
	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>
	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>
	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>
	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>
	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>
	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>
	<553A34D4.70405@bestsolution.at> <553A60F4.9040000@oracle.com>
Message-ID: <CAEnqZEV1oKNkv=Kh5egeQG7qSn+W41zdWHXAuhq87P-XaDFwYQ@mail.gmail.com>

On Fri, Apr 24, 2015 at 5:27 PM, Donald Smith <donald.smith at oracle.com>
wrote:

> Yes, but then read the rest of the thread.  You really must not rely on
> the theoretical possibility of an XX flag that magically kicks all your
> problems down the road a year or two.  The best time to get all this nailed
> correctly is now.


I understand why you are writing this and in principle I agree. But please
understand that this is not about fixing sloppy programming in a college
project but affects whether we can use a technology for the next few years
where the problems that stop us now may have gone away or otherwise not to
be able to continue our product using Java (at least until we know where
Java/JFX is going) and move to something native instead throwing away huge
investments. The world is just not that simple.



> That flag is not likely to be as extensive and durable as everyone is
> imagining.
>
> OK, so having to patch the JDK to access private API in Java 9 is still a
possible outcome?

From philip.race at oracle.com  Fri Apr 24 16:06:45 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 24 Apr 2015 09:06:45 -0700
Subject: JavaFX always choose monospace font - possible bug?
In-Reply-To: <4b1b79d1ad114cdfcbc8ef347f50e0ae.squirrel@webmail.adamish.com>
References: <4b1b79d1ad114cdfcbc8ef347f50e0ae.squirrel@webmail.adamish.com>
Message-ID: <553A6A15.2090203@oracle.com>

FX should just be asking fontconfig what your set up is.
What do you get if you run the fontconfig command line app ?

$ fc-match sans:regular:roman
Vera.ttf: "Bitstream Vera Sans" "Roman"

-phil.

On 4/24/15 1:30 AM, Adam Granger wrote:
> I'm using a redhat 6 system with jdk 1.8u40 where the only font available
> is "Liberation" in all its variants, bold, italic, mono, serif, sans-serif
> etc.
>
> /usr/share/fonts/liberation
> /usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> /usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
> /usr/share/fonts/liberation/fonts.dir
> /usr/share/fonts/liberation/LiberationMono-Italic.ttf
> /usr/share/fonts/liberation/LiberationSans-Bold.ttf
> /usr/share/fonts/liberation/LiberationSerif-Bold.ttf
> /usr/share/fonts/liberation/LiberationMono-Regular.ttf
> /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
> /usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf
> /usr/share/fonts/liberation/fonts.scale
> /usr/share/fonts/liberation/LiberationSans-Regular.ttf
> /usr/share/fonts/liberation/LiberationSans-Italic.ttf
> /usr/share/fonts/liberation/LiberationMono-Bold.ttf
>
> When I run up a app, even without custom CSS, all the controls,
> textfields, buttons etc are displayed in monospaced liberation.
>
> I've debugged this using -Dprism.debugFonts
>
> Loading FontFactory com.sun.javafx.font.freetype.FTFactory
> Subpixel: enabled
> Freetype2 Loaded (version 2.3.11)
> LCD support Enabled
> Time spent accessing fontconfig=4ms.
> FC font sans:regular:roman maps to Liberation Mono in file
> /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
> File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
> File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font sans:bold:roman maps to Liberation Mono Bold in file
> /usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
> File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
> File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font sans:regular:italic maps to Liberation Mono Italic in file
> /usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
> File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
> File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC font sans:bold:italic maps to Liberation Sans Bold Italic in file
> /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC font serif:regular:roman maps to Liberation Mono in file
> /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
> File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
> File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font serif:bold:roman maps to Liberation Mono Bold in file
> /usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
> File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
> File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font serif:regular:italic maps to Liberation Mono Italic in file
> /usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
> File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
> File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC font serif:bold:italic maps to Liberation Sans Bold Italic in file
> /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC font monospace:regular:roman maps to Liberation Mono in file
> /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   0) Family=Liberation Mono, Style=Regular, Fullname=Liberation Mono,
> File=/usr/share/fonts/liberation/LiberationMono-Regular.ttf
>   1) Family=Liberation Sans, Style=Regular, Fullname=Liberation Sans,
> File=/usr/share/fonts/liberation/LiberationSans-Regular.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font monospace:bold:roman maps to Liberation Mono Bold in file
> /usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   0) Family=Liberation Mono, Style=Bold, Fullname=Liberation Mono Bold,
> File=/usr/share/fonts/liberation/LiberationMono-Bold.ttf
>   1) Family=Liberation Sans, Style=Bold, Fullname=Liberation Sans Bold,
> File=/usr/share/fonts/liberation/LiberationSans-Bold.ttf
>   2) Family=Liberation Serif, Style=Regular, Fullname=Liberation Serif,
> File=/usr/share/fonts/liberation/LiberationSerif-Regular.ttf
> FC font monospace:regular:italic maps to Liberation Mono Italic in file
> /usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   0) Family=Liberation Mono, Style=Italic, Fullname=Liberation Mono Italic,
> File=/usr/share/fonts/liberation/LiberationMono-Italic.ttf
>   1) Family=Liberation Sans, Style=Italic, Fullname=Liberation Sans Italic,
> File=/usr/share/fonts/liberation/LiberationSans-Italic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC font monospace:bold:italic maps to Liberation Sans Bold Italic in file
> /usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   0) Family=Liberation Sans, Style=Bold Italic, Fullname=Liberation Sans
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationSans-BoldItalic.ttf
>   1) Family=Liberation Mono, Style=Bold Italic, Fullname=Liberation Mono
> Bold Italic,
> File=/usr/share/fonts/liberation/LiberationMono-BoldItalic.ttf
>   2) Family=Liberation Serif, Style=Italic, Fullname=Liberation Serif
> Italic, File=/usr/share/fonts/liberation/LiberationSerif-Italic.ttf
> FC name=sans style=0 uses Liberation Mono in file:
> /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>
> It seems that JavaFX makes mappings which I believe to be incorrect, for
> example "sans:regular:roman" maps to Liberation Mono rather than
> LiberationSans-Regular.
>
> Firstly can anyone explain the 1) 2) 3) output that -Dprism.debugFonts
> gives. What does this mean??
>
> Secondly, is this a bug or not? Can anyone advise? Surely JavaFX should
> map the logical font to it's "physical" equivalent, i.e. sans regular =>
> <font name> sans regular, mono bold => <font name> mono bold etc.
>
> I've read over https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup
> but this doesn't help to explain this situation. I saw support for private
> font font directory with -Dprism.fontdir however I'd prefer for JavaFX to
> map to existing fonts in /usr/shar/fonts "correctly"
>
> I also wrote this up at
> http://stackoverflow.com/questions/29828681/javafx-uses-monospaced-font-for-all-controls
> also, but had zero interest.
>
> Regards,
>
> Adam.
>
>
>
>
>


From tom.schindl at bestsolution.at  Fri Apr 24 18:41:59 2015
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 24 Apr 2015 20:41:59 +0200
Subject: Enhancements to 3D for JFX9?
In-Reply-To: <553A60F4.9040000@oracle.com>
References: <F5B652F3-B807-426B-9C80-D8C7D4FF8E41@gmail.com>	<CAC7xrqY423UGBNvjiUZJ6iHe4P6RcCMxZudxQbhhpUJRSP-Tuw@mail.gmail.com>	<5536FB4C.8000501@oracle.com>	<CAOQavC-iLOiQNsX=E0scDC5t==vfrg9SxN+My0ruLD6UyYFCzg@mail.gmail.com>	<76EC2BC7-BF68-4E5A-8717-CD36D5D3C9E0@gmail.com>	<CANEZrP3a7pLf4xD8L0LB9vRuWu06nktd_Qkc7ZbKv0PNMe3UKw@mail.gmail.com>	<CAEnqZEUt83W6dCTbX4urXeoRxcV6FGPG4A-cn6Zu1THbbUCAgA@mail.gmail.com>	<CANEZrP3L91-KA_3wh=XPVaXNSS2b9_jHy1+8bOAvO8er9VLHkw@mail.gmail.com>	<CAEnqZEUF7sGbpNyu9k7w==H23e-ADXdsoXcNS4K+x-MXuLZCbg@mail.gmail.com>	<553A34D4.70405@bestsolution.at>
	<553A60F4.9040000@oracle.com>
Message-ID: <553A8E77.5090507@bestsolution.at>

Hi,

I never proposed to rely on this feature forever but to relax the
concerns raised that JDK9 is the end for useing JavaFX in new not yet
explored ways and people stop using it today because it is already sure
today that you won't get the API you require in your app.

I've already outlined in our EclipseCon meeting with Mark and Alex how
one could go for allowing none global access to not yet finished APIs
without useing the big hammer -XX.... - Eclipse with its @noimplement
and @noextend and Equinox with it's private-package exports show you
ways how this could be address so that eg JavaFX could expose some of
its internal stuff in JKD9.

I think something like that is essential for young modules like javafx.

Tom

On 24.04.15 17:27, Donald Smith wrote:
> Yes, but then read the rest of the thread.  You really must not rely on
> the theoretical possibility of an XX flag that magically kicks all your
> problems down the road a year or two.  The best time to get all this
> nailed correctly is now.  That flag is not likely to be as extensive and
> durable as everyone is imagining.
> 
>  - Don
> 
> 
> On 24/04/2015 8:19 AM, Tom Schindl wrote:
>> Did you read the reply from Phil in the other thread?
>>
>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>> transition.
>> So you will not have to maintain a JDK9 build but only start with this
>> thread to still access private APIs and this is something you can
>> clearly control if you install the JDK with your app!
>>
>> Tom
>>
>> On 24.04.15 14:05, Robert Kr?ger wrote:
>>> On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>>> this may mean, people who do this must work with a patched JDK in the
>>>>> future.
>>>>>
>>>> Right. But I think that's going to be more and more common in
>>>> future. If
>>>> you rely on people installing proprietary stuff like JWS or applets
>>>> then
>>>> it's a bleak future, as the way forward is clearly bundled JREs.
>>>>
>>>>
>>>>
>>> patched != bundled. For us this would be quite a step back, having to
>>> maintain our JDK patches/builds. Bundling itself is fine in our business
>>> cases.
>>>
>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From vadim.pakhnushev at oracle.com  Fri Apr 24 19:40:14 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 24 Apr 2015 22:40:14 +0300
Subject: In(Sanity) Testing Mondays
Message-ID: <553A9C1E.8040902@oracle.com>

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 1pm 
PDT.

Happy testing!

Thanks,
Vadim

From Fabrizio.Giudici at tidalwave.it  Fri Apr 24 23:39:15 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Sat, 25 Apr 2015 01:39:15 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
Message-ID: <op.xxmenpla2ilaq7@localhost>

Ok, I've run into many problems in the past with diacritics, as there were  
some JDK problems, but I supposed they were all fixed today. But perhaps  
there's something I'm not understanding.

I've several files with diacritics in their name, let's say e.g. "La  
Cath?drale Engloutie.m4a". A catalog contains their names, and it has been  
prepared on Mac OS X, JDK 1.8.0_40 and saved with UTF-8 encoding. The  
catalog is read, of course specifying UTF-8 as encoding, on the Raspberry  
PI Rasbian with JDK 1.8.0_33. Everything is correct as I see the proper  
characters in the UI and logfiles.

The problem arises when I try to open a file with diacritics (this doesn't  
happen with all files with diacritics in their name, only with some): I  
get an exception because the file name is not found (both with io and  
nio). Thanks to some suggestions, I made it work by passing the file name  
through Paths.get(Normalizer.normalize(path.toString(), NFD)). This  
transforms the initial encoding for the ? from c3 a9 (doesn't work) to 65  
cc 81.

Now, first I don't understand why I have to take care of this. I'm aware  
that different file systems use different encodings, but I supposed that  
all the conversions were done by the JVM. BTW, both systems are configured  
with:

LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

The Java system properties are:

file.encoding: UTF-8
file.encoding.pkg: sun.io
sun.io.unicode.encoding: UnicodeLittle (ARM) sun.io.unicode.encoding:  
UnicodeBig (Mac)
sun.jnu.encoding: UTF-8

The files on the ARM were rsynced from the Mac. I'm not sure that  
LC_ALL/LANG/whatever were already set when the rsync was performed.

If it's correct that I have to deal with it, is there any official  
documentation I can reference? BTW, I'm not aware of why the NFD  
normalisation is the one who works, and not one of the other three.

Thanks.



-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From mikegps1 at gmail.com  Sat Apr 25 23:28:44 2015
From: mikegps1 at gmail.com (Mike)
Date: Sat, 25 Apr 2015 16:28:44 -0700
Subject: Intel Edison
Message-ID: <AB27FFD5-D53B-44D6-BBEE-F8F71F66BBA3@gmail.com>

Does Intel Edison run jdk8 u40?

The Intel? Edison is an ultra small computing platform that will change the way you look at embedded electronics. Each Edison is packed with a huge amount of tech goodies into a tiny package while still providing the same robust strength of your go-to single board computer. Powered by the Intel? Atom? SoC dual-core CPU and including an integrated WiFi, Bluetooth LE, and a 70-pin connector to attach a veritable slew of shield-like ?Blocks? which can be stacked on top of each other. It?s no wonder how this little guy is lowering the barrier of entry on the world of electronics!
The Intel? Edison packs a robust set of features into its small size, delivering great performance, durability, and a broad spectrum of I/O and software support. Those versatile features help meet the needs of a makers, inventors, and beginners. This is a module with a high speed processor and WiFi and Bluetooth Radios on board. It?s low power and small footprint make it ideal for projects that need a lot of processing power, but don?t have the ability to be near a larger power source or have a large footprint.
If you are looking to add a little more stability to your Intel? Edison stack, check out this Hardware Pack. It will provide you with increased mechanical strength for stacking Blocks on your Edison!
Dimensions: 35.5 ? 25.0 ? 3.9 mm (1.4 ? 1.0 ? 0.15 inches) Max
Features:
Intel? Atom? system-on-a-chip (SoC) based on leading-edge 22 nm Silvermont microarchitecture including a dual-core CPU and single core microcontroller (MCU)
Integrated Wi-Fi, Bluetooth LE, memory, and storage
Support for more than 30 industry-standard I/O interfaces via a 70-pin connector
Support for Yocto Linux, Arduino, Python, Node.js, and Wolfram
Open source community software tools enabling ease of adoption and inspiring third-party app developers to build apps for consumers.
EDI1.SPON.AL.S (System-On-Modules - SOM Edison Module IoT Internal Antenna)

 



We offer the great products with guaranteed quality.

Shipping Terms:

Your order will be processed within 1 to 2 business days after receipt of cleared payment. Transit time varies on shipping option. 
We will automatically email you with tracking information as soon as we process your order, within 1 to 2 business days.
We only ship to the verified PayPal address supplied to us by eBay/PayPal 
Payments:

We Accept Payments Via PayPal Only
Sales Conditions:

14 days in order to get your money back or item exchange, buyer pays return shipping
Buyers Pay for Return Shipping Cost
20% restocking fee will apply on all new items that have been opened and returned (except defective)
Do not return the item before contacting us. Any return must include a return authorization number provided for us. After you report any problem wait for our answer.
Item must be returned within 3 days after RMA instructions has been provided

Sent from my iPhone

From offbynull-openjfx at offbynull.com  Sun Apr 26 02:49:20 2015
From: offbynull-openjfx at offbynull.com (offbynull-openjfx)
Date: Sat, 25 Apr 2015 19:49:20 -0700
Subject: Camera lookAt functionality
Message-ID: <553C5230.2030401@offbynull.com>

When will we get lookAt and lookAt bindings for JavaFX's Camera classes?

I don't think any user wants to have to write this out by hand. If 
you're going to abstract things out to the point of having a Camera 
class, that Camera class should have intuitive ways to orient it.

Even OpenGL has gluLookAt.

From jack at moxley.co.uk  Sun Apr 26 09:10:12 2015
From: jack at moxley.co.uk (Jack Moxley)
Date: Sun, 26 Apr 2015 10:10:12 +0100
Subject: Camera lookAt functionality
In-Reply-To: <553C5230.2030401@offbynull.com>
References: <553C5230.2030401@offbynull.com>
Message-ID: <FCDA943C-CC3E-4493-8E36-6948F8D87029@moxley.co.uk>

+1

Sent from my iPhone

> On 26 Apr 2015, at 03:49, offbynull-openjfx <offbynull-openjfx at offbynull.com> wrote:
> 
> When will we get lookAt and lookAt bindings for JavaFX's Camera classes?
> 
> I don't think any user wants to have to write this out by hand. If you're going to abstract things out to the point of having a Camera class, that Camera class should have intuitive ways to orient it.
> 
> Even OpenGL has gluLookAt.


From kevin.rushforth at oracle.com  Mon Apr 27 13:12:44 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 27 Apr 2015 06:12:44 -0700
Subject: Camera lookAt functionality
In-Reply-To: <FCDA943C-CC3E-4493-8E36-6948F8D87029@moxley.co.uk>
References: <553C5230.2030401@offbynull.com>
	<FCDA943C-CC3E-4493-8E36-6948F8D87029@moxley.co.uk>
Message-ID: <553E35CC.5070208@oracle.com>

We have an RFE filed to deliver such as a utility / sample:

https://javafx-jira.kenai.com/browse/RT-37899

-- Kevin



Jack Moxley wrote:
> +1
>
> Sent from my iPhone
>
>   
>> On 26 Apr 2015, at 03:49, offbynull-openjfx <offbynull-openjfx at offbynull.com> wrote:
>>
>> When will we get lookAt and lookAt bindings for JavaFX's Camera classes?
>>
>> I don't think any user wants to have to write this out by hand. If you're going to abstract things out to the point of having a Camera class, that Camera class should have intuitive ways to orient it.
>>
>> Even OpenGL has gluLookAt.
>>     
>
>   

From mike at plan99.net  Mon Apr 27 13:13:46 2015
From: mike at plan99.net (Mike Hearn)
Date: Mon, 27 Apr 2015 15:13:46 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <op.xxmenpla2ilaq7@localhost>
References: <op.xxmenpla2ilaq7@localhost>
Message-ID: <CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>

Heh. Welcome to Unicode :(

Unfortunately, many file systems especially in the UNIX world do not
precisely specify how file names are to be encoded. Some of them treat file
names as opaque null terminated byte arrays.

Thus this may not be a bug in Java so much as a design problem/oversight
with the operating systems themselves.

Note that the issue you're running in to is *not* to do with encodings.
It's not a UTF-8 vs UTF-16 type issue. Rather, the issue is that Unicode
allows visually identical strings to be represented differently at the
logical layer, using different sequences of code points.

You didn't say what app originally saved the files. However, what exact
sequence of code points you get on disk for a given piece of human readable
text can depend on things as varying as what input method editor the user
typed the file name with, precisely what combination of keys they pressed
and when, what libraries the app used, and so on.

Yes it's a mess.

If you encounter such situations frequently then your best bet may be to
simply write a little wrapper that tries different normalisations until it
finds one that works.

From kevin.rushforth at oracle.com  Mon Apr 27 19:58:24 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 27 Apr 2015 12:58:24 -0700
Subject: 8u-dev and 9-dev unlocked following sanity testing <eom>
Message-ID: <553E94E0.3060707@oracle.com>



From kevin.rushforth at oracle.com  Mon Apr 27 21:52:27 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 27 Apr 2015 14:52:27 -0700
Subject: Intel Edison
In-Reply-To: <AB27FFD5-D53B-44D6-BBEE-F8F71F66BBA3@gmail.com>
References: <AB27FFD5-D53B-44D6-BBEE-F8F71F66BBA3@gmail.com>
Message-ID: <553EAF9B.1050304@oracle.com>



Mike wrote:
> Does Intel Edison run jdk8 u40?
>   

[off topic advertisement for Intel Edison cut]

Did you mean to send what looks like an advertisement for Intel Edison, 
or just you just cut and paste from Intel's web site? I'll presume the 
latter, since it would be inappropriate to spam the list with an offer 
to sell such a system.

In general this would only work if running a desktop OS such as Windows 
8 or Ubuntu Linux (desktop not embedded Linux).

-- Kevin


From mikegps1 at gmail.com  Tue Apr 28 04:56:49 2015
From: mikegps1 at gmail.com (Mike)
Date: Mon, 27 Apr 2015 21:56:49 -0700
Subject: Intel Edison
In-Reply-To: <553EAF9B.1050304@oracle.com>
References: <AB27FFD5-D53B-44D6-BBEE-F8F71F66BBA3@gmail.com>
	<553EAF9B.1050304@oracle.com>
Message-ID: <55A89AC9-54CE-4F73-AE89-46D5AFF44801@gmail.com>

I did not mean to include anything from Intel

My own research appears to indicate jdk8 will run edison 



Sent from my iPhone

> On Apr 27, 2015, at 2:52 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> 
> 
> Mike wrote:
>> Does Intel Edison run jdk8 u40?
> 
> [off topic advertisement for Intel Edison cut]
> 
> Did you mean to send what looks like an advertisement for Intel Edison, or just you just cut and paste from Intel's web site? I'll presume the latter, since it would be inappropriate to spam the list with an offer to sell such a system.
> 
> In general this would only work if running a desktop OS such as Windows 8 or Ubuntu Linux (desktop not embedded Linux).
> 
> -- Kevin
> 

From neugens at redhat.com  Tue Apr 28 06:22:12 2015
From: neugens at redhat.com (Mario Torre)
Date: Tue, 28 Apr 2015 08:22:12 +0200
Subject: Off topic: named parameters
In-Reply-To: <553601C0.2010207@tbee.org>
References: <553601C0.2010207@tbee.org>
Message-ID: <1430202132.3796.34.camel@galactica>

On Tue, 2015-04-21 at 09:52 +0200, Tom Eugelink wrote:
> Totally off topic, I apologise, but the subscribers to this list are the type of people who may have the experience I seek.
> 
> I've been trying to pitch the concept of named parameters for Java 9, but somehow my JEP is never picked up. I emailed it in twice. Has anyone ever successfully handed in a JEP?
> https://tbeernot.wordpress.com/2013/09/29/the-java-9-named-parameter-pitch/
> 
> Tom

Hi Tom,

I personally think this makes the language more verbose with little
benefit, but that's just me maybe.

I don't see your JEP here:

http://openjdk.java.net/jeps/0

You can start off the discussion for a JEP over the mailing list that
more closely matches your change area, if there's no objection, you can
go on and create a bug on the OpenJDK bug database, from there you will
need discussions in order to move the bug to the next state.

A JEP usually means you will need to do the work yourself, unless you
can make such a strong case to get someone to work on the task for you
(one such example, lambdas). In that regard no one will "pick up" your
JEP, you need to actively push.

Changes, unless minor, will have to be reconfirmed by the JCP committee,
so it may very well be that the JEP will just remain a very complex and
complete proof of concept.

The idea behind the JEP is to have a testbed for new ideas, a place
where there's less overhead to experiment with something, and perhaps
contribute quicker to OpenJDK once proved that the changes are small or
self contained, or really worth it.

Here you can find a bit more information:

http://openjdk.java.net/jeps/1
http://openjdk.java.net/jeps/2

And especially this:

http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

Cheers,
Mario



From Fabrizio.Giudici at tidalwave.it  Tue Apr 28 13:06:41 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Tue, 28 Apr 2015 15:06:41 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
Message-ID: <op.xxsz1fr22ilaq7@localhost>

On Mon, 27 Apr 2015 15:13:46 +0200, Mike Hearn <mike at plan99.net> wrote:

> Thus this may not be a bug in Java so much as a design problem/oversight
> with the operating systems themselves.
>
> Note that the issue you're running in to is *not* to do with encodings.
> It's not a UTF-8 vs UTF-16 type issue. Rather, the issue is that Unicode
> allows visually identical strings to be represented differently at the
> logical layer, using different sequences of code points.

Yes, I understand.

>
> You didn't say what app originally saved the files. However, what exact

They were rsynced from Mac OS X. Actually I thought it could be related to  
the piece of software that brought the file on the RPI, but in the end -  
thinking in general - a user could transfer the files in either way, and I  
must be able to deal with them.

> sequence of code points you get on disk for a given piece of human  
> readable
> text can depend on things as varying as what input method editor the user
> typed the file name with, precisely what combination of keys they pressed
> and when, what libraries the app used, and so on.
>
> Yes it's a mess.
>
> If you encounter such situations frequently then your best bet may be to
> simply write a little wrapper that tries different normalisations until  
> it
> finds one that works.

I feared that. In the end it might be even reasonably doable, if I can  
take advantage of some preconditions... for instance: is it safe to assume  
that, given a specific instance of a filesystem, everything is  
encoded/normalised in the same way? In this case I could just run a quick  
test at the start of the application, find once for all the correct  
normalisation, and then always apply the same. Otherwise, I have to try  
all the combinations for every file that I open...

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From mike at plan99.net  Tue Apr 28 13:11:55 2015
From: mike at plan99.net (Mike Hearn)
Date: Tue, 28 Apr 2015 15:11:55 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <op.xxsz1fr22ilaq7@localhost>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
	<op.xxsz1fr22ilaq7@localhost>
Message-ID: <CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>

>
> They were rsynced from Mac OS X.


I said *original* app. Rsync is not the original app and most likely does
not attempt to re-encode or re-normalise Unicode strings.


> I feared that. In the end it might be even reasonably doable, if I can
> take advantage of some preconditions... for instance: is it safe to assume
> that, given a specific instance of a filesystem, everything is
> encoded/normalised in the same way?


Probably not. Most software that handles unicode does not do code point
normalisation. Hence my emphasis on what app created the file name in the
first place.

>

From swpalmer at gmail.com  Tue Apr 28 13:53:16 2015
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 28 Apr 2015 09:53:16 -0400
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
	<op.xxsz1fr22ilaq7@localhost>
	<CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
Message-ID: <CAL3e5iEU0L9vLTuTx17zTFSQtkrJoUtGuKH8iiuAfhge+XZGpg@mail.gmail.com>

I thought Mac OS X has a standard normalization for unicode filenames.
Linux just treats whatever it gets as bytes so it is up to the software
creating the file. Am I correct?

(e.g. see:
http://stackoverflow.com/questions/9757843/unicode-encoding-for-filesystem-in-mac-os-x-not-correct-in-python
)

The point is on Linux, as you say, "it's a mess".  I'm not sure there is
anything that can be done by Java or your app that will work 100% of the
time.

Scott

On Tue, Apr 28, 2015 at 9:11 AM, Mike Hearn <mike at plan99.net> wrote:

> >
> > They were rsynced from Mac OS X.
>
>
> I said *original* app. Rsync is not the original app and most likely does
> not attempt to re-encode or re-normalise Unicode strings.
>
>
> > I feared that. In the end it might be even reasonably doable, if I can
> > take advantage of some preconditions... for instance: is it safe to
> assume
> > that, given a specific instance of a filesystem, everything is
> > encoded/normalised in the same way?
>
>
> Probably not. Most software that handles unicode does not do code point
> normalisation. Hence my emphasis on what app created the file name in the
> first place.
>
> >
>

From kevin.rushforth at oracle.com  Tue Apr 28 14:07:44 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 28 Apr 2015 07:07:44 -0700
Subject: Intel Edison
In-Reply-To: <55A89AC9-54CE-4F73-AE89-46D5AFF44801@gmail.com>
References: <AB27FFD5-D53B-44D6-BBEE-F8F71F66BBA3@gmail.com>
	<553EAF9B.1050304@oracle.com>
	<55A89AC9-54CE-4F73-AE89-46D5AFF44801@gmail.com>
Message-ID: <553F9430.2050909@oracle.com>

If running a full desktop OS, then it should do, yes.

-- Kevin


Mike wrote:
> I did not mean to include anything from Intel
>
> My own research appears to indicate jdk8 will run edison 
>
>
>
> Sent from my iPhone
>
>   
>> On Apr 27, 2015, at 2:52 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>>
>>
>> Mike wrote:
>>     
>>> Does Intel Edison run jdk8 u40?
>>>       
>> [off topic advertisement for Intel Edison cut]
>>
>> Did you mean to send what looks like an advertisement for Intel Edison, or just you just cut and paste from Intel's web site? I'll presume the latter, since it would be inappropriate to spam the list with an offer to sell such a system.
>>
>> In general this would only work if running a desktop OS such as Windows 8 or Ubuntu Linux (desktop not embedded Linux).
>>
>> -- Kevin
>>
>>     

From Fabrizio.Giudici at tidalwave.it  Tue Apr 28 14:13:15 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Tue, 28 Apr 2015 16:13:15 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
	<op.xxsz1fr22ilaq7@localhost>
	<CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
Message-ID: <op.xxs24dn82ilaq7@localhost>

On Tue, 28 Apr 2015 15:11:55 +0200, Mike Hearn <mike at plan99.net> wrote:

>>
>> They were rsynced from Mac OS X.
>
>
> I said *original* app. Rsync is not the original app and most likely does
> not attempt to re-encode or re-normalise Unicode strings.

Ok. The original app is iTunes.

>> I feared that. In the end it might be even reasonably doable, if I can
>> take advantage of some preconditions... for instance: is it safe to  
>> assume
>> that, given a specific instance of a filesystem, everything is
>> encoded/normalised in the same way?
>
>
> Probably not. Most software that handles unicode does not do code point
> normalisation. Hence my emphasis on what app created the file name in the
> first place.

Point taken, but in the end I'm using iTunes, while other people could use  
everything else. If it's up to the original app, this means that any user  
using any app can generate any encoding/normalisation. So, if I  
understand, there are no assumptions I can do.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From mike at plan99.net  Tue Apr 28 14:40:36 2015
From: mike at plan99.net (Mike Hearn)
Date: Tue, 28 Apr 2015 16:40:36 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <CAL3e5iEU0L9vLTuTx17zTFSQtkrJoUtGuKH8iiuAfhge+XZGpg@mail.gmail.com>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
	<op.xxsz1fr22ilaq7@localhost>
	<CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
	<CAL3e5iEU0L9vLTuTx17zTFSQtkrJoUtGuKH8iiuAfhge+XZGpg@mail.gmail.com>
Message-ID: <CANEZrP3T+tHN384ymw+zo8Q2ub486O7o0BBXxXgR=bQJWtoTTQ@mail.gmail.com>

>
> I thought Mac OS X has a standard normalization for unicode filenames.
> Linux just treats whatever it gets as bytes so it is up to the software
> creating the file. Am I correct?
>

Looks like you are:

https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties

So HFS+ does define a normalization form, which is apparently something
very close to but not identical to NFD. Good to know.

From chien.yang at oracle.com  Tue Apr 28 22:47:15 2015
From: chien.yang at oracle.com (Chien Yang)
Date: Tue, 28 Apr 2015 15:47:15 -0700
Subject: Code Review Request For RT-39856: Layout Regression - bad row height
Message-ID: <55400DF3.5060005@oracle.com>

Hi Kevin,

Please review the proposed fix.

JIRA: https://javafx-jira.kenai.com/browse/RT-39856

Thanks,
- Chien

From phdoerfler at gmail.com  Wed Apr 29 14:21:50 2015
From: phdoerfler at gmail.com (=?utf-8?Q?Philipp_D=C3=B6rfler?=)
Date: Wed, 29 Apr 2015 10:21:50 -0400
Subject: How to get raw pixel data into JavaFX
Message-ID: <49B07552-A492-4AC0-B7B4-3B46EAFAD710@gmail.com>

Hello list,

I got some very low level pixel data residing in memory with a pixel format and want to get that into JavaFX. I am talking about raw bytes, BGR, 24 bit per pixel etc..
The library providing this pixel data is OpenCV and although it allows for encoding the data into a standard format like ".bmp" or ".png" which then can be read by JavaFX, I would like to avoid this extra conversion process because I got some real time constraints.

As far as I understand this is what the PixelReader and PixelWriter interface is for. Is this correct? Where can I find additional information on how to use them besides the Javadoc? Would using the Canvas be easier? Can I somehow use the GraphicsContext of Canvas to do that?
I'd be grateful for any pointers even when it's just "check out the class XZY in the underlying prism code: <link to bitbucket>".

Thanks and best regards!

Philipp D?rfler

From hastebrot at gmail.com  Wed Apr 29 14:29:39 2015
From: hastebrot at gmail.com (Benjamin Gudehus)
Date: Wed, 29 Apr 2015 16:29:39 +0200
Subject: How to get raw pixel data into JavaFX
In-Reply-To: <49B07552-A492-4AC0-B7B4-3B46EAFAD710@gmail.com>
References: <49B07552-A492-4AC0-B7B4-3B46EAFAD710@gmail.com>
Message-ID: <CANdUZf9HPKbZ4V2cOnNq0Fj8bkLKCDdf76u3ax-xgxLjqQ-1Mw@mail.gmail.com>

Hi Philipp,

as far as I know PixelWriter, WritableImage and ImageView fits better for
handling raster images than Canvas.

TestFX uses PixelWriter.setArgb() to convert screenshots from Glass with
Monocle to PNG files:

https://github.com/TestFX/TestFX/blob/fd75122/subprojects/testfx-core/src/main/java/org/testfx/service/adapter/impl/GlassRobotAdapter.java#L230

--Benjamin

On Wed, Apr 29, 2015 at 4:21 PM, Philipp D?rfler <phdoerfler at gmail.com>
wrote:

> Hello list,
>
> I got some very low level pixel data residing in memory with a pixel
> format and want to get that into JavaFX. I am talking about raw bytes, BGR,
> 24 bit per pixel etc..
> The library providing this pixel data is OpenCV and although it allows for
> encoding the data into a standard format like ".bmp" or ".png" which then
> can be read by JavaFX, I would like to avoid this extra conversion process
> because I got some real time constraints.
>
> As far as I understand this is what the PixelReader and PixelWriter
> interface is for. Is this correct? Where can I find additional information
> on how to use them besides the Javadoc? Would using the Canvas be easier?
> Can I somehow use the GraphicsContext of Canvas to do that?
> I'd be grateful for any pointers even when it's just "check out the class
> XZY in the underlying prism code: <link to bitbucket>".
>
> Thanks and best regards!
>
> Philipp D?rfler

From morris.meyer at oracle.com  Wed Apr 29 18:34:21 2015
From: morris.meyer at oracle.com (Morris Meyer)
Date: Wed, 29 Apr 2015 14:34:21 -0400
Subject: [8u60] request for review: RT-40644: [Mac]: The "Custom colors ..."
	dialog can not show as expected
Message-ID: <5541242D.9020009@oracle.com>

Jonathan and Leif,

Please review the css changes for Caspian and Modena for the color 
picker custom color chooser.  We need a bit more than 1em for 
"settings-unit" in CustomColorDialog.java when running on Mac 10.10.  
Tested on 10.10.4.

Thanks much.

         --morris

JIRA - https://javafx-jira.kenai.com/browse/RT-40644
WEBREV - http://cr.openjdk.java.net/~morris/RT-40644.01/



From Fabrizio.Giudici at tidalwave.it  Wed Apr 29 20:07:08 2015
From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici)
Date: Wed, 29 Apr 2015 22:07:08 +0200
Subject: JDK 1.8.0 33/40, diacritics and file problems
In-Reply-To: <CANEZrP3T+tHN384ymw+zo8Q2ub486O7o0BBXxXgR=bQJWtoTTQ@mail.gmail.com>
References: <op.xxmenpla2ilaq7@localhost>
	<CANEZrP1e0rqBWQiODf093vTVHZ0egxXdCNmVvQoU2Qv-Y-t8+A@mail.gmail.com>
	<op.xxsz1fr22ilaq7@localhost>
	<CANEZrP08mRXDEoTMbDJcVFEmKJtgJY6R_AK4i0KvkmP67-LL3g@mail.gmail.com>
	<CAL3e5iEU0L9vLTuTx17zTFSQtkrJoUtGuKH8iiuAfhge+XZGpg@mail.gmail.com>
	<CANEZrP3T+tHN384ymw+zo8Q2ub486O7o0BBXxXgR=bQJWtoTTQ@mail.gmail.com>
Message-ID: <op.xxvd56e42ilaq7@localhost>

On Tue, 28 Apr 2015 16:40:36 +0200, Mike Hearn <mike at plan99.net> wrote:

>>
>> I thought Mac OS X has a standard normalization for unicode filenames.
>> Linux just treats whatever it gets as bytes so it is up to the software
>> creating the file. Am I correct?
>>
>
> Looks like you are:
>
> https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties
>
> So HFS+ does define a normalization form, which is apparently something
> very close to but not identical to NFD. Good to know.

Thanks for pointing out. It's the kind of documentation I was searching  
for. So, NFD is the right thing, but it might not work in some cases. I  
hope they are corner cases not feasible with typical names of music tracks.

In any case, it makes sense to have one's own Java application to provide  
support for getting the files, so names can be processed before they go to  
the filsystem. I'll probably add a WebDAV interface or such.

Thanks.

-- 
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it

From cnewland at chrisnewland.com  Thu Apr 30 17:07:58 2015
From: cnewland at chrisnewland.com (Chris Newland)
Date: Thu, 30 Apr 2015 18:07:58 +0100
Subject: JavaFX amd64 linking against glibc 2.14?
Message-ID: <708f6a84181fb39ffc79febe1b97fcd2.squirrel@excalibur.xssl.net>

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


From morris.meyer at oracle.com  Thu Apr 30 17:09:26 2015
From: morris.meyer at oracle.com (Morris Meyer)
Date: Thu, 30 Apr 2015 13:09:26 -0400
Subject: [9-dev] Request for review: RT-40607: Mac resize cursors are wrong
Message-ID: <554261C6.5070307@oracle.com>

Kevin and David,

Please review my changes to GlassCursor.m to fix the lack of proper Mac 
NW, SW, SE and NE resize cursors.

As the look-up for these cursors was a little involved, I opted to use a 
one-time cache so as not to induce any noticeable visual lag when 
setting these cursors.

Thanks much,

         --morris

JIRA - https://javafx-jira.kenai.com/browse/RT-40607
WEBREV - http://cr.openjdk.java.net/~morris/RT-40607.01/


From kevin.rushforth at oracle.com  Thu Apr 30 17:16:13 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Apr 2015 10:16:13 -0700
Subject: JavaFX amd64 linking against glibc 2.14?
In-Reply-To: <708f6a84181fb39ffc79febe1b97fcd2.squirrel@excalibur.xssl.net>
References: <708f6a84181fb39ffc79febe1b97fcd2.squirrel@excalibur.xssl.net>
Message-ID: <5542635D.4080609@oracle.com>

It's a known bug, for which a fix is in progress:

https://javafx-jira.kenai.com/browse/RT-40550

-- Kevin


Chris Newland wrote:
> 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
>
>