Sounds like an interesting project. I agree that having robust, cross-platform, out-of-the-box (or an easy to install extension) would be valuable. Good luck with it, and I hope to see some updates from you as you make progress.
Best, Nick On Apr 20, 2021, 11:32 PM -0400, Christoph Läubrich <lae...@laeubi-soft.de>, wrote: > Thanks Ned and Nick for the feedback. > > jGL is a pure java impl so no graphics-card memory involved. This might > sound strange, but there are two problems with the native ones: > > 1) I always have had issues regarding different OS, library versions, > driver combinations and so on, and its hard to get bugfixes > 2) Most of the time its hard to integrate these as SWT sadly does not > ship e.g. with at least one "reference" implementation that could be > used out-of-the box (lwjgl3-swt even don't integrate with default SWT GL...) > > I also don't need ultra-high gaming performance but a solid and working > solution cross-platform. > > If you are interested take a look at the examples here > https://github.com/jzy3d/jzy3d-api/tree/master/jzy3d-emul-gl they use > AWT but working really well and with acceptable performance, so I > investigate how to best port that to SWT. > > Am 20.04.21 um 21:12 schrieb Ned Twigg: > > There are modern-ish (Open GL 3/3.2) SWT components maintained here: > > https://github.com/LWJGLX/lwjgl3-swt <https://github.com/LWJGLX/lwjgl3-swt> > > > > Ned Twigg > > Lead Software Engineer, DiffPlug LLC > > 540-336-8043 (cell) > > 888-513-6870 (fax) > > 340 S Lemon Ave #3433, Walnut, CA 91789 > > > > ᐧ > > > > On Tue, Apr 20, 2021 at 12:09 PM Nick Edgar <n.a.ed...@gmail.com > > <mailto:n.a.ed...@gmail.com>> wrote: > > > > 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/ > > <https://www.eclipse.org/swt/opengl/> > > > > Best, Nick > > On Apr 20, 2021, 2:15 PM -0400, Christoph Läubrich > > <lae...@laeubi-soft.de <mailto: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 > > > > <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 > > > > <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 <mailto: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 <mailto:platform-dev@eclipse.org> > > > > > To unsubscribe from this list, visit > > > > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > > <https://www.eclipse.org/mailman/listinfo/platform-dev> > > > > > > > > _______________________________________________ > > > > platform-dev mailing list > > > > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > > > > To unsubscribe from this list, visit > > > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > <https://www.eclipse.org/mailman/listinfo/platform-dev> > > > > > > > _______________________________________________ > > > platform-dev mailing list > > > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > > > To unsubscribe from this list, visit > > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > <https://www.eclipse.org/mailman/listinfo/platform-dev> > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > <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
