GUIMark Home
Home | Detailed Analysis | Benchmark and Rendering Engine theory
GUIMark is a benchmark test suite designed to compare the rendering systems of several popular UI runtimes. In general it should be able to give designers and developers a good indication of which technologies can draw complex interfaces at a smooth rate of motion. The test mostly addresses RIA technologies like Flash, Silverlight, HTML or Java, but was designed to be easily ported to any 2D GUI environment. The basis for this project was inspired by the Bubblemark animation test, but was designed to heavily saturate the rendering pipeline and determine what kind of visual complexity is achievable in the sub-60 fps realm.
The Test
The reference design was originally created in Flex and then ported to the technologies listed below. All results listed in the matrix as well as the detailed results page were run on the same Macbook Pro running Leopard for OS X, and running Win XP under a Boot Camp partition. Each test case was run 3 times in a new browser instance and the highest framerate observed was recorded. For the HTML test, the fastest performing browser on a each OS was used in the comparison matrix (Internet Explorer 7 and Safari 3 won for their respective OSes). All subsequent plugin based tests for the OS were tested in those browsers.
My hope is to port the benchmark to all the other untested technologies listed below and I fully welcome any optimizations or ports that readers want to contribute. I’m really curious to see if any community experts or platform engineers are able to speed up their technology of choice. Although the code is fairly simple at a glance, there are no easy optimization paths to be found (and no cheating by turning off anti-aliasing).
Results
Results for Win XP running on Macbook Pro Intel Core 2 Duo 2.33 GHz
| Tech Base | Version | Average FPS | Source |
|---|---|---|---|
| Browser | HTML | 28.36 / IE 7 | Download |
| SVG | - | - | |
| Canvas | - | - | |
| Flash | Flex 3 | 46.08 | Download |
| Flash 9 | - | - | |
| Java | Java 5 Swing | 19.37 | Download |
| Java 6 Swing | - | - | |
| Processing | - | - | |
| JavaFX | - | - | |
| Silverlight | Silverlight 1 / Javascript | 9.12 | Download |
| Silverlight 2 Beta / C# | 7.95 | Download |
Results for OS X 10.5 running on Macbook Pro Intel Core 2 Duo 2.33 GHz
| Tech Base | Version | Average FPS | Source |
|---|---|---|---|
| Browser | HTML | 18.20 / Safari 3 | Download |
| SVG | - | - | |
| Canvas | - | - | |
| Flash | Flex 3 | 8.01 | Download |
| Flash 9 | - | - | |
| Java | Java 5 Swing | 7.19 | Download |
| Java 6 Swing | - | - | |
| Processing | - | - | |
| JavaFX | - | - | |
| Silverlight | Silverlight 1 / Javascript | 5.25 | Download |
| Silverlight 2 Beta / C# | 5.38 | Download |
Findings
I’ve been surprised with the results so far between WinXP and OS X. On the same machine its very clear which vendors take more advantage of the underlying hardware. The results for the different plugin technologies aren’t too surprising since it’s regularly admitted that most companies spend their optimization time on Windows due to its larger install base. This argument doesn’t hold any water though when comparing html rendering on Safari/Mac against IE /Windows where there’s roughly a 1.6 : 1 advantage to the IE team. I can’t help but wonder if the core apis on the Mac platform are creating any unnecessary roadblocks. I’m also extremely surprised at the rendering speed that Flash is able to pull off on Windows. I developed this benchmark under OS X and after compiling the results I’m considered making the testcase more intensive since Flash is running so fast, but for now maybe the really poor Mac performance will give Adobe something to work on.
You can read more about rendering engine theory, the structure of the test case itself, and detailed analysis of the results on the sub pages within the site.
Updates
John Dowdell from Adobe brought up a valid point that plugin vendors are restricted by the browser environments they run in. This is true to an extent, but the limitations enforced on plugins don’t come into play with the GUIMark test. Browsers typically restrict the number of event loops available to a plugin which caps the framerate to around 40 - 50 fps. GUIMark doesn’t come anywhere close to hitting that limit on Mac. There are also no restrictions to the amount of cpu available to a plugin running within the browser which is why all of them peg the cpu to 100%. To illustrate the point, I created an AIR implementation of GUIMark and ran it on my Powerbook and here are the results I got. The Flash players rendering engine performs no differently outside the browser then it does inside the browser. Until plugins start bumping up against the event loop or Beam Sync restrictions, Adobe, Sun, and Microsoft don’t get a free pass for slow performance on Mac.



May 21st, 2008 at 2:55 pm
This is awesome, Sean, and I’m really surprised too. Have you already hacked up the Processing test? I’d like to understand this a bit better; I might want to do that one
Cheers
May 22nd, 2008 at 11:01 am
take it the windows version was running in IE?
Lets keep in mind thats fucking simplistic compared to Safari which antialiases text correctly and antialiases images, rounded corners and has true opacity compositing.
May 22nd, 2008 at 11:12 am
I ran 2D animation & rendering tests using a particle system a month ago. Results were inline with yours. Stuck with HTML/Ajax. Performance was a factor. But open standards & ubiquity were bigger factors
The result that continues to surprise is the poor performance of Flex apps on OSX. I just can’t believe this still hasn’t been addressed yet.
Nice work! Are you planning to create a database people can submit results to?
May 22nd, 2008 at 11:32 am
Just to clarify, the IE tests were run on IE 7 under Windows with ClearType enabled at the OS level. PNG opacity is correctly composited under IE 7 and since bitmap antialiasing is built into the image and not calculated by the browser, I don’t think that Safari renders any “truer” then IE. IE does have 1 problem with text clipping but I thats my fault and I need to update the CSS.
I’ll let other more knowledgeable then me debate the differences between Windows ClearType and whatever Apples font rendering system is.
May 22nd, 2008 at 11:49 am
DG, if anyone wants to contribute a test or try optimizing a current one I’ll be glad to host it and run the test on my machine to post results. I wanted to make sure the fps results listed here though are all based off the same machine so it keeps the results more apples to apples.
May 22nd, 2008 at 11:55 am
Linux results (2.66 Core 2 Duo, radeon):
HTML/firefox 5fps
HTML/konqueror 17fps
Flash 23fps
Java6 1.5fps
Silverlight 0 (not supported)
May 22nd, 2008 at 12:13 pm
I found your benchmark results to be very interesting, especially in light of the performance on non-Windows platforms. Am I correct in my reading that you are testing the effectiveness of the development tools to produce compiled animations for maximum framerates?
If so, you might also consider the browser’s rendering plug-in as a bottleneck. On Linux, I have noticed far superior .swf rendering using the Flash 10 beta plugin (http://labs.adobe.com/technologies/flashplayer10/) vs the official Flash 9 plugin release, and I would expect the newer plugin would improve performance on OS X as well.
May 22nd, 2008 at 12:23 pm
Your Silverlight results seem tainted. In order to perform Silverlight 1.0 test you should uninstall Silverlight 2.0 first and install only Silverlight 1.0. Silverlight 2.0 (beta) does indeed perform the worst (in Windows Vista at least, where I tried it). But before installing SL2, the SL1 test was going at a respectable 22-26fps. After installing SL2, the same test barely made it to 10fps.
May 22nd, 2008 at 12:32 pm
Windows Vista, Dual Core 3.0 running at 3.6. Silverlight 2 Beta 1, Flash 9. IE7
HTML: 32.06
Flex: 36.31
Java/Swing: (wouldn’t load)
Silverlight/JavaScript: 21.54
Silverlight 2 B1: 11.6
I’m going to look at the SL2 code and see if there’s anything funky going on in there.
Pete
May 22nd, 2008 at 1:22 pm
30fps on all three - windows vista / ie7. my video card isn’t that good either.
May 22nd, 2008 at 1:23 pm
Interesting test. I was surprised at the Silverlight 2 performance so I did my bit of investigation. At first the performance on this laptop was about 8 FPS.
First, I changed the timer from 17ms to 1 tick as this would otherwise delay the rendering of frames up to 17ms since your timer thread and the SL rendering threads are not being synchronized, creating a time gap. This pushed the performance up to about 11 FPS. Note that the proper way of creating a synched loop is by hooking up to storyboard events.
Second, Silverlight rendering is also on a timer that can create another time gap. This is configurable through the CreateObject/CreateObjectEx framerate property, or Settings.MaxFramerate. In Application_Startup I added “this.Host.Settings.MaxFrameRate = 1000;”. This pushed the performance up to about 16 FPS.
Double the original speed! But I am still unimpressed, so I set out to find a bottleneck.
Finally, I found the culprit: text rendering! I removed the text from Holder.xaml, and the performance was up to about 500 FPS!
Hopefully in B2 or RTM the text rendering will be highly optimized, and we can see the expected performance.
May 22nd, 2008 at 1:32 pm
Alexandre, try it again but this time hit the “Run Test” button and let me know your final average fps or send me a link to the test result. As I noted on this page http://www.craftymind.com/guimark-results/ Silverlight 1 and 2 have a bad timer object and queues up callbacks to fire twice in a row even though it will only render once. The lower the Timer, the more often it will occur and the higher the simulated fps will be. You can see it in the raw data packets when using the “Run Test” option and I explicitly filter it out in the final chart. In my tests setting a 1ms Timer versus a 17ms Timer didn’t actually increase the rendering rate, it just called the fps counter more often then it should.
May 22nd, 2008 at 3:20 pm
Hi Sean, I have made some changes to your code to remove the dispatcher timer thread in exchange for a storyboard loop:
private Storyboard storyboard = new Storyboard();
private void initStoryboard()
{
storyboard.SetValue(Storyboard.TargetNameProperty, “loop”);
// note: must set x:Name=”cParent” in Page’s XAML root canvas
(FindName(”cParent”) as Canvas).Resources.Add(storyboard);
storyboard.Completed += new EventHandler(storyboard_Completed);
storyboard.Begin();
}
int frametimer;
int lastframetimer = 0;
void storyboard_Completed(object sender, EventArgs e)
{
frametimer = getTimer();
if (frametimer != lastframetimer)
{
processFrame();
lastframetimer = frametimer;
}
storyboard.Begin();
}
[ .. ]
public void UserControl_Loaded(object sender, RoutedEventArgs e){
panImage1.DataContext = this;
panImage2.DataContext = this;
fpsOutput.DataContext = this;
initStoryboard();
//System.Windows.Threading.DispatcherTimer frameLoop = new System.Windows.Threading.DispatcherTimer();
//frameLoop.Interval = new TimeSpan(0, 0, 0, 0, 17); // 17 Milliseconds
//frameLoop.Interval = new TimeSpan(1);
//frameLoop.Tick += new EventHandler(processFrame);
//frameLoop.Start();
}
I also changed all the calls to getTimer() to use frametimer, just for fun
So I see the repeat timer value issue now! It seems the timer values are “snapped” to frame timings. So with “if (frametimer != lastframetimer)” the FPS won’t go above 64 no matter what, even setting maxframerate to a value above 64 - or a frame each 15ms. Perhaps it’s locked to my laptop’s screen refresh rate (60hz)… or perhaps only a MS engineer in some secret facility knows the truth behind this *ahum* synch mechanism.
So (drumroll) without the text, this is the chart I got (64.01):
Link
Obviously, re-adding the text still makes it slow as hell.
May 22nd, 2008 at 3:47 pm
Interesting. I had read that MS was discouraging the use of the Storyboard object for managing timer loops post 1.0. The textblock is a significant portion of the benchmark since most all RIAs contain text and it really stresses the layout engine. It also plays an important equalizer in balancing out the things HTML is good at, with the things the plugins are good at. Although ultimately Flash just chews through both text and graphics with ease.
May 22nd, 2008 at 3:57 pm
“I’ve been surprised with the results so far between WinXP and OS X.”
Try it outside of a browser, in a Projector or in AIR. The Mac browsers have been a little dictatorial in the timeslices they’ll allot to plugins.
It’s been an issue for a few years, but not a well-known one. Chet Haase did a new analysis last month:
http://graphics-geek.blogspot.com/2008/04/times-up.html
jd/adobe
May 22nd, 2008 at 4:05 pm
Indeed, I am shocked by the performance of text rendering in Silverlight 2 Beta 1… especially knowing that MS has been coding very fast text renderers since the early days of Windows. I would rather use some sort of dispatcher timer than the ugly storyboard code above but it doesn’t seem like it plays well with the renderer yet.
In short, Microsoft has some work to do, but obviously they know this hence the Beta 1 - already quite a few months old so I imagine it has evolved quite a lot! It will be interesting to try this again on Silverlight 2 final and compare the results.
May 22nd, 2008 at 4:30 pm
John, this first round was designed for browser based UI technologies and when I start moving my test to AIR you guys will be up against WPF and Cocoa, and I imagine that battle is going to be just as interesting
I think its important that Adobe, Sun, and Microsoft use their weight to make both Mac and Win browsers into better platforms for plugins since it appears to be out of the control of the common developer. At the end of the day, if developers find they’ll get better performance out of HTML derived RIAs over plugin based ones, excuses or not, they might start moving that direction.
May 22nd, 2008 at 5:00 pm
(Thanks Sean, but the point was that the Mac browsers themselves have been the cause of Mac/Win performance differences in the past, as shown by running outside the browser, on the desktop. Make sure to test them Cocoa apps on Windows too…!
(I’m not sure how much influence we can exert on Apple or Mozilla, and for Microsoft we had to endure the whole Eolas thing. But competitive pressures will provide an equalizer, if Mac users see that AIR outperforms in-browser apps.)
jd
May 23rd, 2008 at 11:18 am
Oddly, I found very different results when I did a recent 3D transition test for SlideRocket in Flex. On the Mac, performance was better than on my PC.
Here are links for the tests, one using Papervision in Flash Player 9 and the other using native 3D in Flash Player 10. The FP10 performs best in full-screen mode.
http://www.sliderocket.com/test/fp9test.html
http://www.sliderocket.com/test/fp10test.html
mitch
sliderocket
May 23rd, 2008 at 11:38 am
Thanks Sean for setting up this benchmarking project.
Could you provide what browser you used with the various plugin tests, since it’s possible that the browser is effecting the performance of the plugin? Thanks.
Also for those who are interested, here’s more information on framerates for the Flash player on different operating systems and different browsers, right from an Adobe engineer, Tinic Uro:
http://www.kaourantin.net/2006/05/frame-rates-in-flash-player.html
May 23rd, 2008 at 1:28 pm
Mitch, how do you feel about the performance of the core Slide Rocket app aside from the 3d transitions? Your app is a great example of the visual complexity that is slowly becoming the norm in RIAs, and is a primary example of why GUIMark stresses so many different visual features. When I ran your demos I had a chance to put them side by side to actually watch them. I noticed that the framerate was higher on Mac when idle, but they’d both drop to about the same level when running the transition. Visually they both had the same relative amount of stutter in the transitional period. One thing about Windows though is there was alot of image tearing occurring, whereas Mac had better image quality.
Matthew, I just realized that I didn’t post which browsers won on the home page, I only mention it in the detailed analysis so I added that into the page above. I tested on IE 7 and Safari 3 for the respective OSes. Both you and John posted about the same issue and I know I’m going to see this alot. What Tinic is refering to is a maximum possible framerate allowed by both the browser and the OS. Since GUIMark comes nowhere near those caps, the only thing being stressed is the quality of the renderer itself. Once Mac is pushing 30 fps or higher, then it will start becoming applicable.
May 23rd, 2008 at 4:58 pm
Thanks for providing such a effective benchmark !
it really shows what vendors are up to and metrics help them speed these things up
well done
regards
John Jones
http://www.johnjones.me.uk
May 24th, 2008 at 7:35 am
My results on C2D 6600 2.4 GHz(only 3% faster than yours), FF3b5 and Ubuntu 8.04:
HTML: 21
Flash: 52
Java: 18
May 24th, 2008 at 9:31 am
I have tried the HTML test on my Mac Pro on these browsers under Mac OS X:
Safari 3.1
Webkit nightly
Firefox 3 RC1
and on these browser under Windows XP SP3:
Safari 3.1
Firefox 3 RC1
Internet Explorer 7
The difference in FPS between the results on my machine is between 1-3. I would like to point out that I just reinstalled Windows XP so its not bloated with anything that slowes it down.
May 26th, 2008 at 3:22 am
Wow, this crawls on Firefox 3 RC1. 5-6 FPS!?
Flash/Flex - 26 FPS
Tested on a XP SP3 Athlon 3500+.
May 27th, 2008 at 4:35 am
It’s great that you’ve put this together, I’m very impressed that you could develop this in so many different languages. I’m not convinced that the reflowing of text on each frame makes for a very real world test. I don’t think any text rendering system is going to be optimised for reflowing text that often, and I can’t think of a design that would use that capability. I think that bitmap resizing and transforming as in Mitch’s test should be included in the benchmark as this is fairly widely used in RIAs (think of all those coverflow and flipbook clones). There should also be some form of alpha channel animation element. I have found it is in these areas that you need to reach the framerate for the animation to be effective on the chosen platform and if the framerate is not high enough then the effect is lost and users get annoyed with your unresponsive interface.
May 27th, 2008 at 10:29 am
Just curious, did you optimize Mac OS X for performance?
Since Mac OS X for portables uses settings that optimizes various aspects of the user experience such as “Better Performance”, “Better Battery Life”, or a cross between the two, which setting did you use when you performed these tests? Mac portables tend to emphasize battery life over performance, so you should probably optimize the OS as much as possible for performance if that’s what you care about. I imagine that XP already runs the CPU much hotter than Mac OS X to maximize performance, though equivalent settings on the XP side should be optimized for performance as well.
Ultimately, what you may have inadvertently discovered is not that Mac OS X makes inefficient use of the hardware, but rather makes highly efficient use of the hardware to optimize user experience and not necessarily raw performance.
May 27th, 2008 at 10:58 am
So SlideRocket has both an editor for creating presentations and a player for playing them back. We’ve seen very few performance issues with the editor. The GUI is very responsive and is pretty comparable with a desktop app. Thumbnail generation is probably the worst performing aspect since we can’t do it server-side and there is no threading in the client.
Older builds of SlideRocket definitely attempted to have more GUI eye candy (sliding drawers, etc) but it quickly became clear that that stuff was difficult to maintain good performance with.
I’m reasonably happy with baseline playback performance but I think our biggest challenge is that SlideRocket is flexible enough that a user can bring it to it’s knees quite easily. Drop a snow particle plugin on top of an HD movie and then put a drop shadow effect on it and you are hosed.
If anyone would like a beta account for SlideRocket, please feel free to email me at mitch@sliderocket.com
May 27th, 2008 at 11:29 am
Stephen - Thanks. I think its a valid argument that the benchmark goes a bit overboard on text reflow, but since almost all websites are mostly text driven, I wanted this test to be valid for simple transitions like Digg and Slashdots commenting system, all the way up to more complicated visual system. The test stresses a good amount of matrix transforms as well as vector transforms, but theres no way I’d be able to rewrite Papervision in each different language. That kind of test is really going to have to remain a Flash thing only.
Scott - I ran the tests with my power cord plugged in and my laptop set to ‘Better Performance’ for the power cord setting. One thing to also point out is that I kept both my Activity Monitor and Task Manager open during testing to ensure that my cpu was pegged to 100%. This was a pretty important aspect of the test for me since I didn’t want to build something that wasn’t correctly thrashing the cpu.
May 27th, 2008 at 11:46 am
Maybe comparing like-for-like may have been slightly more fair.
You’re comparing Leopard with an OS that’s been around since 2001, why didn’t you compare Apple’s latest OS (Leopard), with Microsoft’s latest OS? (Vista)
Or if you want to compare Microsoft’s most updated and speed-optimised OS (XP), then compare it against the same from Apple - i.e. Tiger, which has had 11 updates since its release.
Leopard is an OS that’s only had a couple of updates, and also has a lot more eye-candy than Tiger, and is far from speed-optimised.
May 27th, 2008 at 1:12 pm
Darby, its just a matter of what I have installed on my machine. As for Tiger, I just got one of my coworkers to run the HTML test in Safari on his Tiger install. He saw a slightly lower framerate then I got in Leopard at 17.19 fps. Here are the raw results. Personally I think XP results are more relevant right now since it owns such a large market share compared to vista.
May 27th, 2008 at 4:29 pm
For the java benchmark, could you please run it on 6u10 (beta builds
available from http://jdk6.dev.java.net ). This benchmark will benefit from the new Java2D pipeline which was added in that release, assuming you have a decent video board.
I get pretty much the same scores as Flex on my system with 6u10 installed.
Thanks,
Dmitri
Java2D Team
May 27th, 2008 at 9:14 pm
I just ran this on my iMac, under both Mac OS X 10.5.2 and VMWare Fusion with Windows XP SP3. VMWare Fusion w/ WinXP comes close to the published numbers for Windows XP, both in windowed and fullscreen mode. My OSX reaches the same sad numbers as published. It’s a shame that emulated Windows apps get more performance than apps running directly on the host system.
Supposedly Apple has told users of the latest dev seeds for OS X 10.5.3 to report back on Flash performance in Safari, and the Mac native software Delicious Library 2 mentions drastic rendering speed improvements that will be available with OS X 10.5.3, so there is hope
May 28th, 2008 at 2:39 pm
The difference between IE7 and Safari basically just boils down to image scaling. Safari as much higher quality image scaling than IE7 does, so our rendering of the scaled image is superior. However this higher quality scaling comes at the expense of speed.
On my machine if I switch WebKit to use lower quality scaling, we jump from 21fps to 35fps. So basically that explains the difference. You might consider forcing IE to use higher quality image scaling:
http://msdn.microsoft.com/en-us/library/ms530822(VS.85).aspx
I’m going to look into making WebKit dynamically switch to lower quality scaling if an image changes size repeatedly and quickly (going back to high quality mode when the animation stops). That should ideally provide the best of both worlds (high quality scaling for static scaled images, and fast low quality scaling when an animation scale is happening).
May 28th, 2008 at 6:12 pm
Thanks for the info Dave. I’m surprised those 4 stars are causing that much trouble since all the other images on the page are being clipped and repositioned vs scaled. I imagine Safari is limited by Beam Sync so ~35 fps is going to be the max you can hit?
May 28th, 2008 at 8:04 pm
I have some other optimizations that push the result close to 40fps on my Mac Pro (up from 21fps when I first started hacking).
It’s worth noting that if you dropped the cross-browser code you could cut out a significant # of elements for a more optimized rendering (for example border-image on a single div instead of a bunch of table rows and cells).
May 29th, 2008 at 12:42 am
Grattz for the test …
Why not Vista vs. OS X 10.5 ?!?!?
MS dont sell XP now, only Vista left
May 29th, 2008 at 1:12 pm
Up to to 43fps on my machine.
Patches should be landing soon, and then you will be able to try out a WebKit nightly and see for yourself.
May 30th, 2008 at 3:34 pm
Hi,
I think this is a great post and the findings are very interesting!
I was wondering if your tests could handle CURL as well?
http://www.curl.com/
It would kill two birds with one stone for me, the XP vs Mac thing as well as being able to see how CURL compares to Flash and Java in a rendering situation (their current tests have been based on JPEG encoding which doesn’t really seem relevant).
More info:
http://developers.curl.com/blogs/community_blog/2008/05/12/comparing-the-performance-of-curl-and-flex-3
Thanks in advance!
Cheers,
Chris
May 30th, 2008 at 4:14 pm
My changes have landed if you are interested in trying out a nightly build.
http://nightly.webkit.org/
June 10th, 2008 at 5:13 pm
Hmm, The HTML test on Windows 2003 is almost twice as fast in IE7 than FF3 RC2; wasn’t expecting this…
June 11th, 2008 at 4:17 pm
[Microsoft - Silverlight Performance]
This benchmark was very interesting to investigate, as mentioned earlier our text rendering was a major bottleneck with this scenario. We’ve made several optimizations to text performance as a result (caching glyph paths, better detection of what’s outside the clipping bounds). These features will be integrated when we release the final version of Silverlight 2 and show substantial improvement with this scenario.
Additionally our timers have been improved and now fire reliably. You will be able to use either the DispatcherTimer or StoryBoardTimer and see the same results.
June 15th, 2008 at 11:41 am
Shane, good to hear, I’ve been getting such good feedback from all you major vendors that I imagine I’ll have to make a new test in the future to start breaking all your optimizations again. I look forward to testing the final plugin.
June 18th, 2008 at 7:04 pm
Sean,
We have identified the bottleneck in the Flash Player for OSX. Like in the other plugins the culprit is text rendering, in this case rendering using device text. This benchmark spends >50% in a single OSX function: ATSUGetUnjustifiedBounds. You can verify this yourself using Shark. I am working on a change which will cache the results returned by that API to where this call should completely disappear from the performance profile.
If everything turns out well I hope to see that change in future release. Some new numbers on my Mac Pro (note that these represent numbers which can change at any time if we decide to do things differently):
Before the change: ~8.5fps
After the change: ~28fps in Safari (~26fps in Firefox)
(On the same machine I get this for the HTML test: Firefox 3 RC3: ~14fps, Safari 3.1.1: ~21fps, WebKit nightly: ~42fps)
These numbers are for the plugin. There are still issues with the plugin API on OSX. I assume other plugins will also hit a ceiling. When I use the standalone Flash Player I get this:
Before the change: ~9fps
After the change: ~42fps
I should also point out the 3+ different ways you can render text in Flash. If you want to be totally fair you should embed a font and render it using the different anti-aliasing options. This is closer to what Silverlight and Java do.
Lastly I want to mention that the Flash Player is optimized for both x86 and PPC. It always has been. But these kind of benchmarks are really useful for us to identify platform specific bottlenecks like in this case.
June 19th, 2008 at 11:29 am
Nice Tinic,
That’s great to see a 3x performance increase in the browser.
I’m still curious why the standalone player is getting such higher performance then the browser plugin since we’re still far below the event loop cap? I just ran a quick Flex test and saw that my event loops in Firefox were capped at around 50 fps. If the standalone player can hit 42 fps shouldn’t the browser as well?
Is AVM2 written in Carbon or Cocoa on OS X?
June 24th, 2008 at 7:07 am
no tweaking necessary, just run the tests noobs and stop trying to skew the numbers because you bought into the OS X hype
on Vista x64/IE7
32fps HTML
what’s interesting is FF3 is slower
July 3rd, 2008 at 11:58 am
Why are you doing:
timer = new Timer(17, this);
in the Java benchmark ? - I am limited to 32 fps, and if I remove this restriction I go up to ~ 60fps.
July 3rd, 2008 at 12:24 pm
I was going through the Java code and there are some small things that are being done “wrong”:
* new Date().getTime() => System.currentTimeMillis();
* use of double precision (Java is more precise than most when using doubles - change to float).
With these changes I got ~ 70+ fps (I changed to 10 second sampling, due to too high fluctuations)
I then switched to the Server vm by passing -server, and my fps increased to ~ 120 (!).
Oh the joys of benchmarking
July 5th, 2008 at 5:29 am
ha IE7 speed, yeah great but now check how it renders the page.
it’s complete shambles, being inaccurate of course gives u a speed advantage this isn’t down to good coding practice just lazy coding practice.
July 31st, 2008 at 6:14 pm
Sorry, but this benchmark is just misleading - it only shows that you know how to program in Flex, but dont know how to do it in Java.
You expect that Java is forgiven your lazy coding, but it doesnt.
Try to optimize your class with the comments above and you will see, that Java is quiet alot faster then any other of your testers.
August 11th, 2008 at 3:41 am
Does anyone know how flash player reacts to multiple processors? Looking at performance in iStat it seems to lean on one processor only.
August 17th, 2008 at 5:05 pm
I’ve read elsewhere also numbers which suggest that Java kicks ass. Would like to see some benchmark tests of the Java applet loading time and best performance vs Flash loading time and best performance. Especially in the areas of 3D as well as 2D rendering. Found this unbelievable pure-Java 3D engine from about a DECADE ago called idx3D (an example demo is http://www.idx3d.ch/idx3d/demo6.html) vs PaperView3D for Flash. Flash will have native 3D in the next version and maybe Java will also provide native 3D. Would also like to see best-performance 2D comparison.
August 31st, 2008 at 4:38 pm
please run the test with java 6 update 10 too. Comparing old versions against new isn’t fair.
October 8th, 2008 at 6:19 am
Have difficulties to run a test on Silverlight 2 Beta 2. Anyone else?
October 16th, 2008 at 6:14 am
I would like to check a Silverlight RTW version of GUIMark. I would appreciate an updated benchmark
October 17th, 2008 at 10:27 am
the info on this page is out of date…no silverlight 2 final release and no flash 10.
October 18th, 2008 at 9:19 pm
There is something curious about this.
I got the same results running the test in Mac OS X 10.5.5, using version Flash 10. However, I run the thest in windows XP on Fusion 2.0 and I also got the same results. I did not get the hyper fast renderings you have here.
It seems the problem is related to Mac OS X graphics subsystem.
I new Silverlight 2 example update to finale version would be nice also.
October 21st, 2008 at 9:09 pm
I updated the Silverlight 2 beta code to Silverlight 2 RTW. Check out the results/demo/code here:
http://www.silverlighthack.com/post/2008/10/21/Silveright-2-RTW-Performance-GUIMark.aspx
Microsoft has fixed the Text Glyph rendering and Silverlight 2 RTW and the performance is pretty much the same as Flex 3.
October 22nd, 2008 at 3:15 pm
I updated the Silverlight beta 1 code with Silverlight 2 RTM. There is a dramatic positive change in Silverlight 2 performance…
http://www.silverlighthack.com/post/2008/10/21/Silveright-2-RTW-Performance-GUIMark.aspx