Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] most performant way to paint a (platform-specific) pixel-array

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



Back to the top