IE 7 pulled off the fastest rendering for the HTML test among Windows based browsers. the framerate chart to teh right baffles me more then any other chart listed on this page since the highs and lows are so rapid and don’t appear to correspond to any direct actions within the test.

Firefox pulled off the slowest average fps for the HTML test on Windows. Maybe Mozilla could use a chunk of that money they’re supposedly raking in to hire someone to work on their rendering engine.

Opera faired slightly better then Firefox on the Windows HTML test, but the graph really shows just how much different the renderers are working in the 2 different browsers.

On the Mac side, Safari just barely took top spot among the other browsers in the HTML test. I had really hoped to see a better showing out of the Safari team when going head to head with Internet Explorer under Windows on the same hardware. Consider yourself officially “On Notice” Safari.

Just like Windows, Firefox 2 came in last in the HTML test for Mac. Not much more to add apart from whats already been said.

Not too shabby there Opera team! The framerate exibited on the HTML test under Mac Opera was so close to Safari that any number of possible test conditions could see Opera pull ahead under different configurations. Not bad considering their not as close to the OS as the Safari team.

Flex 3 on Windows handily beat out all other runtimes tested on both Windows and Mac. Even though Adobe pretty much rewrote the Flash Player for version 9, it looks like they incorporated the past 10 years worth of rendering research into the latest player.

Flex 3 showed the biggest difference in frame rate between Mac and PC. I may be mistaken but its possible that the Flash player for Mac is still optimized for the PowerPC processor and hasn’t been moved over to the Intel base. The big dips on the graph occur when the center text block is at its largest size during the test run. The layout calculations are pretty significant at that point.

I had always read that Java could spank Actionscript when it came to code execution. I’m not sure if thats still true but I do know that Swing doesn’t hold a candle to Flash’s DisplayObject architecture. These numbers had me questioning whether I had written my Swing code correctly. It might not be as optimized as it could be, but I’m sure alot ofthis is out of teh hands of user code.

Swing has some serious issues running on Mac under Java 5. For those of you able to run the benchmark under Mac, the “Pause” and “Run Test” buttons are really there, you just can’t see them until you click them, so click around the space below the fps timer and you eventually hit them.

Of all the tests built for GUIMark, I was looking forward to building the Silverlight tests the most. I haven’t had alot of reasons to play around with the SDK and this was the perfect opportunity. From a framework perspective, XAML is a worthy competitor to Flex even though the component architecture could use some work. From a rendering perspective, Silverlight has a LOT of growing up to do. In fact, the framerate listed above is a lie. In Silverlight 1 users had to rely on the Storyboard object to fire timed events, but those events would occasionally queue up and fire twice in a row before rendering the output. Thats why on the chart you see those massive spikes in framerate. The “real” framerate is more in the range of 5 to 6 fps.

One good thing you can say about Silverlight is that rendering performance is closer together on Windows and Mac then the Flash player is.

I felt that Silverlight deserved a fair chance to compete with the other environments and that Silverlight 2 with compiled C# was the truer environment that Microsoft wants to push. It also gave me a chance to test the theory that the GUIMark testcase wasn’t constrained by user code, but instead the rendering engines built in to each runtime. Instead of using the Storyboard object for creating timers, i was able to switch to the TimerDispatcher class. Although you don’t see the massive spikes anymore, Silverlight 2 is still prone to queuing up timer events and dispatching 2 at a time and you’ll notice in the chart where the framerate goes above 60 because of this problem.

The Silverlight 2 framerate on Mac is practically identical to Silverlight 1, as is the chart. Again this shows just how little of an effect there is between dynamic and compiled user code when it comes to rendering performance.