widget style cleanup

[Maksim Orlovich]

>> You're getting ahead of yourself, but no problem w/the move itself.
>> However, plastik needs some performance work.
> To be honest, I didn't notice these general performance problems.

I am not sure they're noticeable, they're easily measurable.

> So if you could help me identifying them, I would love trying to improve
> this situation.

Please see the attached .cpp file; apologies for the uglyness, not meant
to be any sort of production code. This is basically what I used to tune
keramik --- it just hammers on PE_ButtonCommand which for Ker hits the
core rendering path -- and I think Plastik is similar with its bevel
rendering accessible from here and occuring all over the place (please
correct me if I am wrong)

Here, when I run this with Keramik, I get it finishing in 26.5 seconds, of
which 15.5 are in-process (that's the "clock:" line, the portions is -way-
too high, likely due to all the temporary TilePainter objects; I hope
nextgen designs I do can eliminate that; hard to do w/the current
codebase).  Light3 comes in at much quicker 9.2 seconds... Plastik takes
200 seconds to run this app here, with 88 in-process, which is 7.5 times
slower than keramik, and 21.7 times slower than Light3. A candidate for a
drag on speed are all the save()/restore() calls, but I am not sure: for
some reason I recall these functions as being slow, but I don't have a
rationale.


-Maks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestBtnSpd.cpp
Type: application/octet-stream
Size: 1428 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040914/9149ce8c/attachment.obj>