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.
On Apr 20, 2021, 11:32 PM -0400, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>, 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.edgar@xxxxxxxxx
<mailto:n.a.edgar@xxxxxxxxx>> 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
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>>, 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
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>>, 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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
