For OpenGL stuff, you want to avoid Image / ImageData and keep as much of the rendering in OpenGL as possible, running on the graphics card. Copying memory between GPU and main memory (Java heap) will be slow. SWT has bindings to some OpenGL libraries, but I don’t think they’ve been updated in quite a while. Have a look though: https://www.eclipse.org/swt/opengl/
Best, Nick On Apr 20, 2021, 2:15 PM -0400, Christoph Läubrich <lae...@laeubi-soft.de>, wrote: > Hi Nick, > > currently I don't have any measures and just trying to collect some > information. My use case is to integrate a software OpenGL render (jGL) > and for that I need to store the rendered pixels somewhere and of course > later I need to paint them. > > I just wondering if I could short-circuit some of the steps > (imagedata>image>gc) and maybe write directly inside some kind of > direct-buffer. > > For example if I look at > > org.eclipse.swt.graphics.Image.init(ImageData) for GTK there seem to > happen some more action than simply keeping a reference to the image > data, e.g. a scale factor is computed, copy of data is involved, color > transformation and so on are performed. > > Maybe as you mention it does not matter, on the other hand the faster > the better here (maybe) this also is a bit depending on the effort to > make this happen here of course but I'd like to investigate a bit if I > should take some internals into account before starting to implement the > actual thing. > > > Am 20.04.21 um 19:19 schrieb Nick Edgar: > > Hi Christoph, > > > > That approach is generally the recommended way to paint images > > <https://www.eclipse.org/articles/Article-SWT-images/graphics-resources.html> > > in > > SWT. Painting of a pre-created Image should be as fast as the OS allows. > > Have you measured the times involved? Which phase do you need to speed up: > > > > 1. creating ImageData, > > 2. creating Image from ImageData, or > > 3. painting Image? > > > > If 1, see if you can directly manipulate the ImageData’s data, or using > > setPixels > > <https://github.com/eclipse/eclipse.platform.swt/blob/eae1f39bbc4fdd01ac0416927ed3fa2d50ec9a9f/bundles/org.eclipse.swt/Eclipse%20SWT/common/org/eclipse/swt/graphics/ImageData.java#L1307>. > > If 2, check which image format you’re using — it may not map directly to > > the native display, and thus be expensive to convert. > > If 3, I’d be surprised, but it would be good to know details and the > > times for 1,2,3. > > > > Best, Nick > > On Apr 19, 2021, 5:20 AM -0400, Christoph Läubrich > > <lae...@laeubi-soft.de>, wrote: > > > I have a pixel-buffer and like it o be painted in the most performant > > > way onto a SWT Canvas. > > > > > > Current approach is to convert this into an ImageData, create an image > > > and then paint it inside PaintListener to the GC. > > > > > > Is there a way to avoid this intermediate steps? I won't mind if I need > > > to provide platform-specific implementations if it is possible to gain > > > performance here. > > > _______________________________________________ > > > platform-dev mailing list > > > platform-dev@eclipse.org > > > To unsubscribe from this list, visit > > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
