[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] SWT-OpenGL rendering in different thread
Junglas,
        I'm going to have a go and a batch line draw interface over the weeken.

        It's not just crossing JNI multiple times that concerns me, but also setting up the native drawing environment multiple times.... also changing color..... i'd like to quickly sort all operations into colors to reduce calls to the native GDI.... for 2D virtual coord transforms could be accelerated, clipping... etc etc...

        I know.... I'm a bit of a performance dweeb..

Paul Anderson
Java Performance Principal
Banking Center of Excellence

paul-anderson@xxxxxxxxxx

Try Gentoo Linux (www.gentoo.org)


From: Junglas Bodo <junglas@xxxxxxxxxxxxx>
To: "Eclipse Platform SWT component developers list." <platform-swt-dev@xxxxxxxxxxx>
Date: 10/22/2009 08:52
Subject: Re: [platform-swt-dev] SWT-OpenGL rendering in different thread
Sent by: platform-swt-dev-bounces@xxxxxxxxxxx




Hi,,

don't get me wrong here, but actually you are describing a display  
list ;)

No, seriously, your idea is quite nice: Write some OpenGL wrapper in  
java that encodes all commands in a nicely packed byte array and just  
hand it to some native component to do the work. The intriguing part  
about this solution is that most of the necessary code could actually  
be generated and that the actually rendering can be transparently done  
either in one thread or in multiple threads by the native component  
best suited for the current runtime environment.
Yes, this indeed has it's charm.

But - even though I'm still in a very early proof of concept phase -  
I'd say that the necessary work to assemble the OpenGL commands from a  
scene model and the actually rendering in the GPU counts much higher  
than the JNI overhead; especially when using display lists. (We're  
talking about reducing about 30-40 JNI calls to one.)

Anyhow, back to my original question: Are there any pitfalls when  
interacting the the GLContext in a different thread than the display  
thread?

I kind of answered this for myself: Yes there are. Plentiful.
The little dirty hack I've mentioned in my first mail seems to work  
for SWT-Cocoa, but obviously not for SWT-win32 (not tested gtk so far).
The problem seems to be the interaction with the (not thread-safe)  
GDI ... <insert here: long triad why mac is some much cooler ;) >

I still have to sort out the details, but in my opinion on needs some  
kind of callback in the GLCanvas, like:
  FutureTask queueRender(Runnable callback)
whereas the GLCanvas can decide (or be configured to) execute the  
callback either in the display thread or a different one (in case of  
win32 maybe both: Create a compatible DC and GLContext in render  
thread and do the buffer swapping in display thread)



Am 21.10.2009 um 10:03 schrieb Gorkem Ercan:

> Coincidentally, we are implementing such a command buffer for our  
> eSWT port on Qt. The main goal of the buffer is to reduce the number  
> of thread switches if the drawing is done on a thread other than UI  
> thread. At this time we are not doing anywork for reducing the JNI  
> calls but just thread switching. Perhaps our work can be reused on  
> all the SWT ports.
>
> Also such a command buffer that reduces the JNI calls existed on the  
> earlier eSWT Symbian S60 port.
> --
> Gorkem
>
>
> On Tue, Oct 20, 2009 at 9:06 PM, Paul Anderson <paul-anderson@xxxxxxxxxx
> > wrote:
> Hi
>
> A few years ago I was looking for a way to render many 2D primitives  
> quickly, I had profiled SWT and noticed that it naturally crosses  
> JNI on every draw call and there is a large around this.....
>
> I imagined a batch interface in which primitive draw instructions  
> and their parameters are placed in an int/float array and passed in  
> bulk to the native code for rendering .... I'm going to resurrect  
> that idea shortly to see what happens.
>
> int[] batch = { SWT.DRAW_LINE, 0,0,100,100, SWT.FILL_CIRCLE,  
> SWT.BLACK, 0,0,200,200  . . . . . . . };
> display.render(batch);
>
>
> OpenGL may well be able to use the same mechanism and it is based on  
> similar concepts ,one could then render in a different thread, then  
> just throw the batch(ogl scene) over to the native code on a  
> designated rendering thread.
>
>
>
> Paul Anderson
> Java Performance Principal
> Banking Center of Excellence
>
> Mobile:+31-651788098 (preferred),  Home Office:+31-70-362-9501,  
> Office:+31-20-513-7388, paul-anderson@xxxxxxxxxx
>
> Try Gentoo Linux (www.gentoo.org)
>
>
> From:                 Junglas Bodo <junglas@xxxxxxxxxxxxx>
> To:                
> platform-swt-dev@xxxxxxxxxxx
> Date:                 10/20/2009 09:55
> Subject:                 [platform-swt-dev] SWT-OpenGL rendering in different thread
> Sent by:                 platform-swt-dev-bounces@xxxxxxxxxxx
>
>
>
>
> Hi there,
>
> at the moment I'm experimenting with the GLCanvas and asked myself why
> the access to the OpenGL context is so tightly restricted to the
> Display thread.
> More precisely: I would like to do all the OpenGL rendering in a
> background thread without affecting the rest of the UI at all.
> Granted, it's usually a bad idea to mess around with OpenGL in
> multiple threads, but I was thinking about some kind of weighted
> execution queue that would allow me to render some views with higher
> priority than others and of course without blocking any kind of user
> interaction.
>
> As a pure experiment I did this:
> Extended the GLCanvas in my own project (boldly called this
> ExtGLCanvas) and just overrided the checkWidget() method by a weaker
> variant that only checks isDisposed. Then I simply handed all
> rendering stuff previously done via Display.asyncExecute() to a
> SingleThreadPoolExecutor.
> At least with SWT OSX-Cocoa this seems to work like a charm.
>
> So my question is: Am I missing an important point here?
>
> Greets
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>
>
> Tenzij hierboven anders aangegeven: / Unless stated otherwise above:
> IBM Nederland B.V.
> Gevestigd te Amsterdam
> Inschrijving Handelsregister Amsterdam Nr. 33054214
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev


_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Tenzij hierboven anders aangegeven: / Unless stated otherwise above:
IBM Nederland B.V.
Gevestigd te Amsterdam
Inschrijving Handelsregister Amsterdam Nr. 33054214