Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad general purpose 2D graphics performance. #1

Open
mipastgt opened this issue May 6, 2016 · 4 comments
Open

Bad general purpose 2D graphics performance. #1

mipastgt opened this issue May 6, 2016 · 4 comments

Comments

@mipastgt
Copy link

mipastgt commented May 6, 2016

Ok, here is my first attempt to report an issue on this new platform.

TrianglePerformanceTest.java.zip

Even after many years of development the general purpose 2D graphics performance
of JavaFX is still very bad and the question is what can be done to improve this.

When you are doing serious graphics programming you normally have to deal
with a lot of different shapes and in general you will end up using lots of paths
because the world simply does not only consist of simple geometries like circles
and rectangles. The problem with paths in JavaFX is that they are not
hardware-accelerated and even simple polygons or polylines are in fact paths and
as such suffer from this restriction. In practice this means that, if you are lucky
and have to draw lots of rectangles, you can get decent performance but if that
changes and you have to deal with triangles for example you will see a
performance drop of up to two orders of magnitude. The most disappointing observation
in all this is that, depending on your exact scenario, you may even get better
overall performance if you explicitly force JavaFX to use software rendering
via -Dprism.order=sw.

In my opinion, what is urgently needed is an extended set of hardware-accelerated
graphics shapes which must at least include simple polygons and polylines.

In the attached example I try to show what I mean. The exact numbers and behavior
depend on the OS and your hardware but the overall result has been the same
for me on all tested platforms (Windows, Mac).

This performance test shows the drawing performance difference between
rectangles and triangles. You can enter the number of elements and
while the application is running you can toggle between showing rectangles
or triangles. In addition there is a button to start and stop the animation
and you can zoom in and out with the mouse wheel. A text field shows the
current frame rate. Just play around a bit with the numbers and options.

@mkarg
Copy link
Member

mkarg commented Jun 28, 2016

I was able to reproduce the performance problem using TrianglePerformanceTest on a high-end notebook using Windows 8.1, 64 Bit, JRE 8u92 and JRE 9-ea+118: 10000 rectangles run fluent, 2000 triangles reduce frame rate to about one (yes, one) fps. Unless someone posts the ultimate workaround here, I will add this to the OpenJDK JIRA this week.

@jimbok8
Copy link

jimbok8 commented Sep 5, 2016

With a Canvas, you can use more basic commands, which give much improved performance ,due to hardware acceleration:

graphicsContext.beginPath();
graphicsContext.moveTo(px0, py0);
graphicsContext.lineTo(px1, py1);
graphicsContext.lineTo(px2, py2);
graphicsContext.closePath();
graphicsContext.fill();

to fill either triangles or rectangles. See attached file for a modification to TrianglePerformanceTest.java.

TrianglePerformanceCanvasTest.zip

Jim

@mipastgt
Copy link
Author

mipastgt commented Sep 5, 2016

Hi Jim,
thanks for the input but in your program you are only drawing the whole graphic once and then you are just scaling and rotating the canvas. This is conceptually the same as drawing into an image once and then just scale and rotate this image. (Just put a print statement into the updateGraphics method to verify that.) Of course this is much faster (actually this is trivial) but I instead wanted to show what the scene-graph performance is when you really have to animate it.

@mkarg
Copy link
Member

mkarg commented Sep 6, 2016

@jimbok8 What @mipastgt wants to show with this program is the general slow performance of the drawing engine. The program itself makes no sense at all, certainly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants