Jzy3d & JavaFX Performance

[Michael Hoffer]

Hi Martin, hi all,

I just played a little bit with the JavaFX support. I am wondering how the JavaFX integration was technically done. I did similar JavaFX node integration for Qt and WebGL. But with public JavaFX APIs the performance is very bad for larger nodes. I noticed the same performance problems with JZy3d. Do you also use WritableImages? Or do you do a SwingNode approach? 

Recently, I wrote about that in the openjfx mailing-list and asked whether other developers are having the same issues with rendering native or offscreen buffers in JavaFX. For our VWorkflows visualization library and the visual programming IDE VRL-Studio we need much better performance for this than current solutions do offer. We could collaborate and make a design proposal for a public JavaFX API with reasonable performance for rendering external buffers. 

Maybe you'd like to join the openfx mailing-list discussion.

Regards,

Michael Hoffer

-----------------------

http://mihosoft.eu

[Martin Pernollet]

Hi Michael,

Thank you to ping us :)

I actually observed no performance issue with jzy3d/javafx binding but would enjoy you share insight about it.

Our JavaFX port is very naive : we render offscreen (!= headless) and copy each frame in a JavaFX ImageView. Most of the binding is readable from JavaFXChartFactory and subpackages (mouse/keyboard controllers).

I have been working on a project somehow similar to vWorkflow (mainly on the idea of hierarchically nesting nodes of a graph) so I would enjoy helping you further.

Can you send links of the openfx discussion?

Regards,

Martin

 

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Jzy3d".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse jzy3d+un...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Michael Hoffer]

Hi Martin,

here's a link to the archive: http://article.gmane.org/gmane.comp.java.openjdk.openjfx.devel/11516

I actually observed no performance issue with jzy3d/javafx binding but would enjoy you share insight about it.

The problem is that for large views, copying is way too slow and uses too much CPU. This gets even worse on large HiDPI/Retina screens. That is what I have noticed with your implementation too. The AWT version works flawless. The JavaFX version is slow for large views. And in my special case, I see a huge difference between native offscreen rendering and the additional copying via JavaFX. It consumes about 4-5 times more CPU than WebGL in Chrome and almost knocks out my computer. As a reference, see: https://github.com/miho/VFXWebKit and https://www.youtube.com/watch?v=FlIrY1SlNM4 

I have been working on a project somehow similar to vWorkflow (mainly on the idea of hierarchically nesting nodes of a graph) so I would enjoy helping you further.

That's cool :) Sounds very interesting!

Regards,

Michael

[Martin Pernollet]

Hi,

I am using a simple Image object. The WritableImage you mentioned could be more efficient to copy the image data : you can implement a PixelReader reading image data more efficiently.

See here how the renderer copies image data to be displayed in JavaFX ImageView. And see how it could be improved :  

It first get screenshot as a JOGL TextureData object ("image")

Then a BufferedImage copy is created but you don't need it if you can implement a PixelReader reading from the TextureData).

You might try to get data even earlier by seing how AWTGLReadBufferUtil read the buffer to produce TextureData and derive it to return a PixelReader.

Hope that helps! 

[Martin Pernollet]

Hi,

Just noticed I discussed the wrong renderer. In JavaFX I use this one : 

https://github.com/jzy3d/jzy3d-api/blob/master/jzy3d-javafx/src/main/java/org/jzy3d/javafx/JavaFXRenderer3d.java

But you might still make use of WritableImage and PixelReader to avoid creating the BufferedImage copy.

Regards,

Martin