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
|