Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: [platform-swt-dev] SWT-OpenGL rendering in different thread

Hello,
 
You mentioned that JNI overhead is largely impacting performance for SWT with rendering many 2D primitives and that this could also apply to apps that use OpenGL heavily.
 
Another potential solution could be natively compiling SWT along with the Java application that uses it. This is effectively what SWT C++ does. By its very nature, a 100% native solution eliminates the JNI overhead or any managed/native overhead because all calling is native-to-native.
 
If it would be helpful to performance profile with the JNI overhead completely removed, feel free to post some sample code for benchmarking the SWT and/or OpenGL rendering scenarios mentioned above. It might be possible for us to take your Java source code, automatically translate it to C++, and then natively compile it. The resulting executable could then be profiled and would show you just how much (or how little) could be saved by eliminating JNI overhead altogether, kind of a best-case scenario for making more code native. One caveat: SWT C++ only supports Win32 and Windows Mobile at this time.
 
----- Original Message -----
Sent: Tuesday, October 20, 2009 2:06 PM
Subject: Re: [platform-swt-dev] SWT-OpenGL rendering in different thread

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

Back to the top