>> And here is the trivial porting to bare Qt: no more calling of makesplinepath
>> nor strokepath, and we don't depend on existing spline point cache either:
>>
>> void spline::draw(Context* ctx) const
>> {
>> ...
>> }
>>
>> Note that we get rid of all spline approximation code, the strokepath,
>> transformation of path points, etc. -- that's plenty of code right there
>> that goes poof.
>
> Bear in mind that when you have at your disposal a (presumably) efficiently
> implemented spline rendering algorithm, your approach makes sense. When you
> start with plain X11, which has no spline rendering algorithm at all, my
> approach is the proper one
I know. I'm just showing that Qt gives us a lot of functionality -- less code
to be
maintained and worried about. Let Nokia's resources go into that.
I wouldn't dare code anything besides a hello world for Xlib. Porting away from
Xlib
is as close that I ever want to get to it.
Qt has quite a bit of code obviously optimized basing on profiles taken in real
life
scenarios, and that's very helpful. Just a recent case in point:
QTransform (the matrix class) knows if it is a special matrix (rotation, or
scaling, etc)
and choses appropriate code paths based on that so that it always performs the
minimum necessary number of floating point multiplies-and-adds, whether you
multiply QTransforms, or map QPoints.
Qt's drawing code is full of such optimizations, and it represents man years of
effort.
This is the only way to get XCircuit to perform well IMHO.
Cheers, Kuba
PS. Tim, please don't be defensive -- I'm not criticizing your code. I know
full well in
what software environment it came to be, and what the limitations were at the
time.
I don't expect you to have to publicly defend your choices.
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
