Marcus wrote:
>>The problem here is simple - the coordinate system in LibGGI ranges
>>from (0,0) to (oo,oo). Negative starting coordinates happens to work
>>when you use software clipping, but with hardware clipping and drawing
>>the results are undefined.
>>The reason this behaviour should not be changed is that for lines it
>>isn't as simple as truncating negative values to zero. I do not
>>intend to put a full software line-drawer into the matrox sublib
>>for the sole purpose of supporting broken applications.
Not to be a pain, but purely on principal, I think that either all targets
should properly deal with negative coordinates, or the types on the
functions should be changed to unsigned int. Documenting the
coordinate system to be positive is an acceptable way out, but only
if the negative values have some sort of meaning (flags, or perhaps inverse
coords from bottom-right corner). Principal of least surprise --
if the program is "broken" it should break consistantly on all targets
so bugs like this don't creep in on app developers. But that's probably
not the best for performance -- so, at the very least, if it does not
already, LibGGI should have compile-time debug ASSERTs that the coordinates
are positive.
Otherwise, it strikes me that it is the Matrox hardware that is broken, and
if we're going to be minimalistic for it's sake, we should restrict the
coordinate system to (0,0) to (virt.x,virt.y) rather than to (oo,oo), so
that if another card driver comes along for a card that's broken for
off-screen points as well, we can make it's DrawLine as efficient as it
can be just like the Matrox's.
My 2 cents.
--
Brian
