Why does only Silverlight for WP7 have a compositor thread?

Last week I learned that Silverlight on the Windows Phone use开发者_JS百科s a "compositor" thread to cache bitmaps and animations and run them independent of the UI thread. This allows animations to run smoothly even if the UI thread becomes blocked.

My question is: why was this introduced only for WP7, and not Silverlight (web) or WPF?

---

A lot of Microsoft's recent focus has been on Silverlight for Windows Phone 7 (make or break time), so they have added essential features to the phone now that would be in the next version of Silverlight. Basically anything to make the phone look fast/smooth/good.

I heard specific mention of an upcoming feature in Silverlight (browser version) being: "running animation storyboards on a background thread". That was in a recent video (sorry lost the link).

---

To have the compositor thread specifically run on a GPU requires that the hardware running the software has a GPU and that it is sufficicently powerful for the task.

WP7 devices are the first place that they can guarantee that every piece of hardware running Silverlight has a baseline hardware requirement.

If Silverlight tried to do this it would have to move the compositor on to the CPU if the hardware it was running on didn't have a GPU. If that CPU was a single core then on some machines the underlying code would just have become more complicated for no performance gain.

---

The compositor (render) thread runs the GPU on Windows Phone 7 devices.

As a resource constrained device, it's necessary to do all the cool animations to have this stuff running on the GPU with bitmap cached images. I would imagine this was an unavoidable design choice for the Windows Phone 7 platform team to accomplish the kind of visuals that are possible on Windows Phone 7 devices.

Sure, perhaps it will also be relevant to do for WPF and Silverlight in general in due course.

So it's not so much about providing another thread to alleviate load from the CPU. It's a thread to manage the GPU. The UI thread runs on the CPU, handling general UI interaction and all other non-GPU code.