• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SWT, Swing draw image performance

 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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?
Greetings,
Miki
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Miklos Szeles
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
1GB RAM
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:
JCyclicImagePainer.java

TestSwing.java


SWT implementation:
CyclicImagePainter.java


TestSWT.java


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


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.
reply
    Bookmark Topic Watch Topic
  • New Topic