aspose file tools
The moose likes Swing / AWT / SWT and the fly likes SWT, Swing draw image performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide 1Z0-808 this week in the OCAJP forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "SWT, Swing draw image performance" Watch "SWT, Swing draw image performance" New topic

SWT, Swing draw image performance

Miklos Szeles
Ranch Hand

Joined: Oct 21, 2008
Posts: 142

Our client application displays several video streams at the same time. There's a native decoder which decodes the pictures into a BufferedImage using ((DataBufferByte)fBufferedImage.getRaster().getDataBuffer()).getData() to acquire the address of the image data. Basically the second most important(the first one is the decoding speed) performance factor of our application is the drawing speed. We would like to reimplement our client's UI, so at the moment we are considering to choose between SWT and Swing. Since I've read that there's no exact winner between SWT and Swing, I think our most important decision factor is which framework performs better in image drawing.
Can anybody tell me which framework suites best our needs?
Rob Spoor

Joined: Oct 27, 2005
Posts: 19844

I think that image drawing should pose no problem in either. If your painting is slow you should investigate exactly why it is slow. You're not decoding upon painting, are you?

How To Ask Questions How To Answer Questions
Miklos Szeles
Ranch Hand

Joined: Oct 21, 2008
Posts: 142
Of course not, first we decode it to a buffer and then we display the image. Unfortuantelly I do have to say that when we are talking about hundreds of images/sec then draw image performance really matter.
Miklos Szeles
Ranch Hand

Joined: Oct 21, 2008
Posts: 142
I made a little exploration in the subject. I tried to simulate the behaviour of our application. So I wrote a custom widget(both in SWT and Swing) which displays an image and uses a timer(set to 10 ms) to change this image periodically. Each widget displays its framerate. For the test I put several widgets on an 1024x768 sized JFrame/Shell and runned with different widget count.
The environment:
Windows XP SP3
Sun JVM 1_6_0_12
Pentium(R) 4 CPU 2.4GHz
Nvidia Geforce4 MX 440
Here's my observations:
When I choose a lower widget count(5x5 for example) every widget runs on 64FPS(SWT and Swing). I think this behaviour is caused by the fact that Windows XP has a 15.625ms timer resolution, which means that the smallest period is 15.625 which is eactly 1000/64.
The intresting part comes when I use hundred or more widget. I tried with 8x8 widget. Swing produced 45FPS, SWT produced 25FPS. Using 10x10 widget SWT became very slow after a short time.
Widget count Swing framerate SWT framerate
5x5 64 64
8x8 45 25
10x10 40 freeze
20x20 14 Error:No more handles
I also tested the behaviour on a newer machine and I got higher framerates but the tendency was the same. SWT was slower, and died after a short time with several controls.
At the moment I'm trying to find the explanations of the test results. Maybe there's some bug in my SWT implementation(this is my first SWT program). I attach the soure codes, maybe somebady can point me the error in the code. But I have another theory: Swing on Windows XP uses DirectX, but SWT uses the native widgets, native Windows API which uses GDI which is not hardware accelerated and slow. Is this true?
The source files for Swing implementation:

SWT implementation:

And there's a common helper class for calculating the framerate:

I also tried to attach the Eclipse project in case somebody wants to run/modify the test on his/her machine, but I gota .zip files not allowed error
I hope someone can point the problematic part of the code or give explanations for the test results.
I agree. Here's the link:
subject: SWT, Swing draw image performance