Re: Canvas performance on Mac OS
Hi Hervé, That's a valid question :) Probably because a) All my non-UI graphics experience is with immediate-mode / raster systems b) I'm interested in using JavaFX for particle effects / demoscene / gaming so assumed (perhaps wrongly?) that scenegraph was not the way to go for that due to the very large number of nodes. Numbers for my Sierpinski filled triangle example: System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M 1024 MB java -Dprism.order=es2 -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23 fps: 18 fps: 25 fps: 18 fps: 23 fps: 23 fps: 19 fps: 25 java -Dprism.order=sw -cp target/classes/ com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 54 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 There are never more than 2500 filled triangles on screen. JDK is 1.8.0_40 I would say there is a performance problem here? (or at least a need for documentation so as to set expectations for gc.fillPolygon). Best regards, Chris On Tue, March 31, 2015 22:00, Hervé Girod wrote: > Why don't you use Nodes rather than Canvas ? > > > Sent from my iPhone > > >> On Mar 31, 2015, at 22:31, Chris Newland >> wrote: >> >> >> Hi Jim, >> >> >> Thanks, that makes things much clearer. >> >> >> I was surprised how much was going on under the hood of GraphicsContext >> and hoped it was just magic glue that gave the best of GPU >> acceleration where available and immediate-mode-like simple rasterizing >> where not. >> >> I've managed to find an anomaly with GraphicsContext.fillPolygon where >> the software pipeline achieves the full 60fps but ES2 can only manage >> 30-35fps. It uses lots of overlapping filled triangles so I expect >> suffers from the problem you've described. >> >> SSCCE: >> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/ch >> risnewland/demofx/standalone/Sierpinski.java >> >> Was full frame rate canvas drawing an expected use case for JavaFX or >> would I be better off with Graphics2D? >> >> Thanks, >> >> >> Chris >> >> >>> On Mon, March 30, 2015 20:04, Jim Graham wrote: >>> Hi Chris, >>> >>> >>> >>> drawLine() is a very simple primitive that can be optimized with a >>> GPU >>> shader. It either looks like a (potentially rotated) rectangle or a >>> rounded rect - and we have optimized shaders for both cases. A large >>> number of drawLine() calls turns into simply accumulating a large >>> vertex list and uploading it to the GPU with an appropriate shader >>> which is very fast. >>> >>> drawPolygon() is a very complex operation that involves things like: >>> >>> - dealing with line joins between segments that don't exist for >>> drawLine() - dealing with only rendering common points of intersection >>> once >>> >>> To handle all of that complexity we have to involve a rasterizer that >>> takes the entire collection of lines, analyzes the stroke attributes >>> and interactions and computes a coverage mask for each pixel in the >>> region. We do that in software currently for all pipelines. >>> >>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path >>> rasterization. >>> >>> For the SW pipeline, drawLine is a simplified case of drawPolygon and >>> so the overhead of lots of calls to drawLine() dominates its >>> performance. >>> >>> I would expect ES2 to blow the SW pipeline out of the water with >>> drawLine() performance (as long as there are no additional rendering >>> primitives interspersed in the set of lines). >>> >>> But, both should be on the same footing for the drawPolygon case. >>> Does >>> the ES2 pipeline compare similarly (hopefully better than) the SW >>> pipeline for the polygon case? >>> >>> One thing I noticed is that we have no optimized case for drawLine() >>> on the SW pipeline. It generates a path containing a single MOVETO >>> and LINETO and feeds it to the generalized path rasterizer when it >>> could instead compute the rounded/square rectangle and render it more >>> directly. If we added that support then I'd expect the SW pipeline to >>> perform the set of drawLine calls faster than drawPolygon as well... >>> >>> ...jim >>> >>> >>> On 3/28/15 3:22 AM, Chris Newland wrote: Hi 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 horr
Re: Review Request: RT-39975 - AppCDS support for packager
No, I don’t have any stats to share about the performance benefits, sorry. On Mar 31, 2015, at 1:42 PM, Mike Hearn wrote: > Do you have any stats on the perf improvement? My understanding of CDS is > that it was primarily meant to reduce memory usage on systems where multiple > Java apps are running on the same JRE simultaneously. I guess that won't > apply to packaged apps so the only benefit can be startup time. > > On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen wrote: > Correct! > > > On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > >> The bug is restricted - intentional? >> >> I'm guessing this is class data sharing and would make startup of packaged >> apps faster? >> >> On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen >> wrote: >> +1 >> >> On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: >> >> > Kevin, Chris, please review >> > >> > jira: https://javafx-jira.kenai.com/browse/RT-39975 >> > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ >> >> > >
Re: Canvas performance on Mac OS
Why don't you use Nodes rather than Canvas ? Sent from my iPhone > On Mar 31, 2015, at 22:31, Chris Newland wrote: > > Hi Jim, > > Thanks, that makes things much clearer. > > I was surprised how much was going on under the hood of GraphicsContext > and hoped it was just magic glue that gave the best of GPU acceleration > where available and immediate-mode-like simple rasterizing where not. > > I've managed to find an anomaly with GraphicsContext.fillPolygon where the > software pipeline achieves the full 60fps but ES2 can only manage > 30-35fps. It uses lots of overlapping filled triangles so I expect suffers > from the problem you've described. > > SSCCE: > https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/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 consistent
Re: Review Request: RT-39975 - AppCDS support for packager
Do you have any stats on the perf improvement? My understanding of CDS is that it was primarily meant to reduce memory usage on systems where multiple Java apps are running on the same JRE simultaneously. I guess that won't apply to packaged apps so the only benefit can be startup time. On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen wrote: > Correct! > > > On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > > The bug is restricted - intentional? > > I'm guessing this is class data sharing and would make startup of packaged > apps faster? > > On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen > wrote: > >> +1 >> >> On Mar 30, 2015, at 3:11 PM, Danno Ferrin >> wrote: >> >> > Kevin, Chris, please review >> > >> > jira: https://javafx-jira.kenai.com/browse/RT-39975 >> > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ >> >> > >
Re: Canvas performance on Mac OS
Hi Jim, Thanks, that makes things much clearer. I was surprised how much was going on under the hood of GraphicsContext and hoped it was just magic glue that gave the best of GPU acceleration where available and immediate-mode-like simple rasterizing where not. I've managed to find an anomaly with GraphicsContext.fillPolygon where the software pipeline achieves the full 60fps but ES2 can only manage 30-35fps. It uses lots of overlapping filled triangles so I expect suffers from the problem you've described. SSCCE: https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/com/chrisnewland/demofx/standalone/Sierpinski.java Was full frame rate canvas drawing an expected use case for JavaFX or would I be better off with Graphics2D? Thanks, Chris On Mon, March 30, 2015 20:04, Jim Graham wrote: > Hi Chris, > > > drawLine() is a very simple primitive that can be optimized with a GPU > shader. It either looks like a (potentially rotated) rectangle or a > rounded rect - and we have optimized shaders for both cases. A large > number of drawLine() calls turns into simply accumulating a large vertex > list and uploading it to the GPU with an appropriate shader which is very > fast. > > drawPolygon() is a very complex operation that involves things like: > > - dealing with line joins between segments that don't exist for > drawLine() - dealing with only rendering common points of intersection > once > > To handle all of that complexity we have to involve a rasterizer that > takes the entire collection of lines, analyzes the stroke attributes and > interactions and computes a coverage mask for each pixel in the region. We > do that in software currently for all pipelines. > > For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs CPU path > rasterization. > > For the SW pipeline, drawLine is a simplified case of drawPolygon and so > the overhead of lots of calls to drawLine() dominates its performance. > > I would expect ES2 to blow the SW pipeline out of the water with > drawLine() performance (as long as there are no additional rendering > primitives interspersed in the set of lines). > > But, both should be on the same footing for the drawPolygon case. Does > the ES2 pipeline compare similarly (hopefully better than) the SW pipeline > for the polygon case? > > One thing I noticed is that we have no optimized case for drawLine() on > the SW pipeline. It generates a path containing a single MOVETO and LINETO > and feeds it to the generalized path rasterizer when it could instead > compute the rounded/square rectangle and render it more directly. If we > added that support then I'd expect the SW pipeline to perform the set of > drawLine calls faster than drawPolygon as well... > > ...jim > > > On 3/28/15 3:22 AM, Chris Newland wrote: > >> Hi Robert, >> >> >> I've not filed a Jira yet as I was hoping to find time to investigate >> thoroughly but when I saw your question I thought I'd better add my >> findings. >> >> I believe the issue is in the ES2Pipeline as if I run with >> -Dprism.order=sw then strokePolygon outperforms the series of strokeLine >> commands as expected: >> >> java -cp target/DemoFX.jar -Dprism.order=sw >> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line Result: 44fps >> >> >> java -cp target/DemoFX.jar -Dprism.order=sw >> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly Result: 60fps >> >> >> Will see if I can find the root cause as I've got plenty more examples >> where ES2Pipeline performs horribly on my Mac which should have no >> problem throwing around a few thousand polys. >> >> I realise there's a *lot* of indirection involved in making JavaFX >> support such a wide range of underlying graphics systems but I do think >> there's a bug here. >> >> Will file a Jira if I can contribute a bit more than "feels slow" ;) >> >> >> Cheers, >> >> >> Chris >> >> >> On Sat, March 28, 2015 10:06, Robert Krüger wrote: >> >>> This is consistent with what I am observing. Is this something that >>> Oracle >>> is aware of? Looking at Jira, I don't see that anyone is working on >>> this: >>> >>> >>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%2 >>> 2In% >>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%2 >>> 0la >>> bels%20in%20(performance) >>> >>> Given that one of the One of the main reasons to use JFX for me is to >>> be able to develop with one code base for at least OSX 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
Re: What are the plans for Java9?
> > One of the major pain points I see is that the java-packager does not > support to set a splash-screen Does your app really need one? My laptop can throw a Stage onto the screen in about 500msec. Then you can just show your own splash whilst the app loads ...
Re: What are the plans for Java9?
It would be nice if there was official support for mobile app packaging. Cheers, Mark On Tue, Mar 31, 2015 at 11:55 AM, Tom Schindl wrote: > Hi, > > Are there any official plans already for Java9? > > One of the major pain points I see is that the java-packager does not > support to set a splash-screen and also ignores the -splash argument who > works when launching with java ... . > > Another very obvious thing at least on all the windows machine I tried > JavaFX is a black area while resizing stages this makes things look > unprofessional. > > A very special request thing is WebGL support Webkit a customer ask me > for but I guess this is a though thing todo because on windows we only > have DirectX. > > > Tom > > -- > 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 >
What are the plans for Java9?
Hi, Are there any official plans already for Java9? One of the major pain points I see is that the java-packager does not support to set a splash-screen and also ignores the -splash argument who works when launching with java ... . Another very obvious thing at least on all the windows machine I tried JavaFX is a black area while resizing stages this makes things look unprofessional. A very special request thing is WebGL support Webkit a customer ask me for but I guess this is a though thing todo because on windows we only have DirectX. Tom -- 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
Setting hover by the API
Hello, We have a use case where we need to set a kind of bounding box around Nodes to be able to select them easily by touch. In our case we use an interactive transparent Pane containing the Nodes (which are set as transparent to mouse events). We also need to handle correctly the hover state for example. However, as there is no way to set the hover property on a Node by the API, we use the inherit value for the properties we want to set in the Node. We did not see any other way to pass the "pseudo-state" to the Nodes themselves. Is there any other way we did not see, or is there a simpler way than by using this trick on the CSS? Hervé Sent from my iPhone
Re: Review Request: RT-39975 - AppCDS support for packager
Correct! On Mar 31, 2015, at 4:41 AM, Mike Hearn wrote: > The bug is restricted - intentional? > > I'm guessing this is class data sharing and would make startup of packaged > apps faster? > > On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen > wrote: > +1 > > On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: > > > Kevin, Chris, please review > > > > jira: https://javafx-jira.kenai.com/browse/RT-39975 > > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ > >
Re: Review Request: RT-39975 - AppCDS support for packager
The bug is restricted - intentional? I'm guessing this is class data sharing and would make startup of packaged apps faster? On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen wrote: > +1 > > On Mar 30, 2015, at 3:11 PM, Danno Ferrin wrote: > > > Kevin, Chris, please review > > > > jira: https://javafx-jira.kenai.com/browse/RT-39975 > > webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/ > >
