I updated the GUIMark code with Silverlight 2 RTW and I wrote a little article about it. 

http://www.silverlighthack.com/post/2008/10/21/Silveright-2-RTW-Performance-GUIMark.aspx 

I have a demo of the new code working here:

http://www.silverlighthack.com/Examples/SilverlightGUIMark/GUIMark_Silverlight2RTMTestPage.html

So this is what is weird.  You will notice that I have a Frame Rate radio button group, where the user can decide to set the Maximum frame rate: Application.Current.Host.Settings.MaxFrameRate

The default setting is 60.  Technically, this means that is the maximum number of times a render loop will fire per second.  Silverlight 2 RTW has a nice new way to ensure that the render loop fires that many times by using CompositionTarget.Rendering

I originally posted this code yesterday and some people posted in my article that Flas/Flex was showing a 15 FPS improvement over Silverlight.  I thought that was weird.  I started tweaking the MaxFrameRate and found some interesting stuff with the demo.

• If I set the Frame Rate to 10..I get about 10 FPS
• If I set the Frame Rate to 20...I get about 20 FPS
• If I set the Frame Rate to 30...I get about 30 FPS
• If I set the Frame Rate to 40...I get about 40 FPS
• If I set the Frame Rate to 50...I get about 35 FPS
• If I set the Frame Rate to 60..I get about 35 FPS
• If I set the Frame Rate to 70..I get about 35 FPS
• If I set the Frame Rate to 100...I get about 40 FPS
• If I set the Frame Rate to 200...I get about 43 FPS
• If I set the Frame Rate to 500...I get about 45 FPS

I get that as I try to increase the amount of times the render event loop fires there is some overhead..so it makes sense that as I go up the FPS goes down a little.  However, why is it going back up after increasing it to 500??  To me this doesn't make sense.  It almost sounds like there is different logic being used when the Frame Rate is set to something really high.

I know that this is a moot point, since the human eye can't notice anything more than about 31 FPS  But for baselining this is important vs Flash/Flex/JavaFx or testing performance.  Can anyone explain what is going on here??

Please "Mark as Answer" if any of my content helped
Bart Czernicki
http://www.silverlighthack.com | http://www.twitter.com/bartczernicki

I don't know the answer but I can add to the confusion. When I run your test on my dual-core Mac (FireFox) I see the FPS capped when selecting the low rate - no surprise there. However, when I set the rate to 30+ I achieve ~ 26 FPS regardless of the rate, i.e. I don't see any change.  I assume that SL (or the browser) can't request a priority boost from OS but perhaps there is some form of fixed steps on Windows. It would be interesting to get stats from different OS' including versions of Windows.

What I am finding out is that Silverlight is a great platform.  However, it has a lot of things under the covers like this that seem simply weird.  This is a HUGE thing when comparing different platforms and even baselining your own code in Silverlight.

Please "Mark as Answer" if any of my content helped
Bart Czernicki
http://www.silverlighthack.com | http://www.twitter.com/bartczernicki

Got some more "interesting" results for you; using the very same Mac but running Vista in a virtual machine (Parallels) both IE & Firefox show the same results and both are affected by the max-fps settings as you say, although both report approx 40 FPS at 500 which is considerably faster than the naitive OSX. So that would give us a clue that it's the OS implementation that is affected by the max setting rather than the browser. I'd guess that the Win implementation is artifically throttling the FPS for some reason. The setting is very useful as I wouldn't have to worry about time-deltas in game loops if I could restrict the max fps but I wouldn't want to set it to 30 if that constrained it to 26 or set it to high to 40 and get 30+ which would be too quick.  

 Mark, can you tell me how to manually set a higher frame rate on Silverlight on a Windows XP machine?

Any assistance would be appreciated.

 Thanks,

Paul