This is indeed not a "Cool VL Viewer thingy", because the Appearance floater only eats up 3ms per frame on my system (it's already pretty well optimized compared to other viewers), meaning, in the worst case scenario, i.e. when the frame rate is the highest (tested in a skybox at 125fps) and when 3ms more makes the biggest difference, I still get 90fps with the floater open (comparatively, at 20fps the added 3ms per frame represent a loss of only 1.2fps)... While there is (a little) room for more optimizations in this floater, I didn't yet implement them because this kind of floater is rarely used and never left open longer than strictly needed for editing a wearable (thus not impacting everyday's use of the viewer unlike, say, the chat history, the IM floater, the mini-map, the radar, etc, that are often left open during a large part of each session and that have been highly optimized already in the Cool VL Viewer). But even once fully optimized, I don't expect a large gain: it's not simply an UI issue (with the dynamic textures rendering in the preview thumbs), but also a result of how textures for each layer are composited in real time (instead of using a pre-composited baked texture) on the avatar.
I'll have a look at this, but I don't promise anything: the played animation is also used as a flag in the viewer code to determine whether the avatar is in appearance editing mode or not, so it's not trivial to change without risking unexpected side effects (especially in the viewers of avatars around yours, that could get confused about your avatar's state...).
Note also that it's not to your avatar shape to fit a dress, but to the dress to fit your avatar shape, independently from the animation being played... That's the whole point behind the "mesh deformer" idea that is currently under development...
I don't see any "too bright" effect here... If it appears "overexposed" on your system, then it might well be due to a bad graphics driver setting (wild guess: a gamma setting that is imposed by the driver instead of letting each OpenGL application decide about it: such overrides are a
very bad idea to enable in your drivers).