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.