Thanks, but how do you know this is the fault of the graphics programmer?
First of all, it could be a graphics card driver issue, I'll talk about that later. However, let's assume it isn't.
Don't forget, in order to achieve a stylable, editable control like this, we have to go through the appropriate WPF APIs and layers of abstraction. We aren't just telling DirectX or OpenGL what to draw here. The "carousel" you tested from others, is it WPF? Is it true 3D, or just 2D simulating 3D (2D using skew transforms for example)? Furthermore, is it still stylable / XAML based, allowing you to place within it any WPF control you wish while still remaining 3D and editable? I'm curious which carousel you've tested. There's no shame in mentionning company names if you have to.
In my experience, competing 2D carousels are *slower* than our 3D carousel...
But comparing oranges to oranges, the only other true 3D carousels I've heard of are Pavan Podila's ElementFlow, which is a cool work in progress and I'm not sure how finished it is at the moment, and IdentityMine's 3D carousel which I've yet to examine but they were showing it at the PDC. It will be interesting to compare performance with them.
That said, with the default Cardflow with reflections on, there's probably plenty of room for improvement. Can't totally blame it on WPF, though sometimes just upgrading your graphics card driver can make a huge difference. It did for us on two machines I know of. It might be that. Otherwise, have you tried some other view settings in the demo? (Like "Card strip", "Train" or "Corner"?). How about when you shut off Reflections? We feel there's room for making the reflections code faster...
In any case, thanks for the comment, we appreciate all input on what parts of the component you feel need performance work.
VP, R&D, Xceed