I'm curious if anyone else has had similar experiences with WPF ItemsControls (ListVie开发者_JAVA百科w, ListBox, etc), and hopefully some advice for me. :)
Just a regular ListBox, with say... 300-500 items (with or without databinding, made no obvious difference), with virtualizing enabled, when I click and drag the scrollbar "thumb" up and down (scrolling up/down), I notice my CPU (3.4ghz) usage going up to roughly 90%. And while everything is reasonably responsive, it does feel kind of hesitant. I've noticed this with most ItemsControls, and I wonder if it's my computer, or if such CPU usage is a justifiable compromise for the rich interface? It's only ItemsControls that have this behavior; I haven't found ScrollViewer in itself to be slow.
Setting ScrollViewer.CanContentScroll
to false (making virtualizing pointless) sped up scrolling by a great deal. However, item-selections became very slow which I would not have expected. Resizing/layout also takes a hard hit, but that was expected.
When compared to a win32 listbox, which uses < 3% cpu when scrolling the same amount of items, I'm inclined to ask these questions (I'm trying to get away from win32 though :).
Is it just because I'm using XP (sp3, with .NET 4.0)?
Is it my graphics card (NVidia GeForce 7300 GS pcie)?
Or, is what I'm experiencing normal?
I don't have any means right now to test on a different (faster) machine, so I'm relying on the experience of others who would have any idea. It feels to me like WPF was only made compatible with XP and aimed at Vista and higher.
Is there perhaps a WPF program I could run as a benchmark, other than VS/Blend, to get a feel for the general performance of an application that uses WPF?
Thanks for your time. :)
精彩评论