From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 8 Nov 1999 19:27:30 +0100

Re: roblems over matrox fb

> > So we either document that giving negative values to any drawing function is
> > undefined or we make sure every function obeys them as appropriate.
> Bad wording on my side, that is what I mean.

O.K. - which of both do we choose, then.

IMHO a good compromise regarding minimum work at maximum functionality would 
be:

LibGGI does support clipping on all of its primitives. It is permissible to
give negative values to LibGGI and they will be clipped correctly.
Please note, that some accelerators will not support efficient means for
clipping lines that have negative endpoints. Thus it is possible, that
applications making use of negative endpoints will suffer a performance
penalty on some targets. So if you are concerned with speed, negative
coordinates should be avoided.

> > From a consistency point of view, I'd say, that if we accept signed values
> > as input to the function, and if we support clipping at arbitrary windows
> > anyway, we should as well clip correctly, if someone gives negative values.

> > Do the same for Matrox. All it takes is is something like
> > if (x1<0||x2<0||y1<0||y2<0) return fallback_drawline(...);

> But why? I'm very curious about how any application can benefit so
> much from being able to pass negative coordinates that it warrants
> this >10x slowdown? 

It is a convenience thing for vector oriented stuff. I'd say, that if we
clip at all, we should clip correctly for all cases.

If you want to make sure things run perfectly fast, it might be advisable to
clip yourself anyway, as you can clip much faster at the expense of clipping
perfectly. A sentence like the above in the FAQ would make that clear, I
think.

> If there's a valid reason to why negative coordinates should be supported 
> allthough it will slow down _all_ applications (not very much, but still 
> a slow down

It's really not much. If someone wants to squeeze that last few cycles out,
he'll probably hit the HW himself anyway ...

> ) I'd like to hear it.

Consistency and generalization are the arguments IMO. I think if we support
clipping and support negative values (we have signed  types in the calls),
we should as well clip the negative values. Moreover why should stuff look
differently when I am on frame 0 or 1 (frame 1 has room for negative coords
below ...). Regarding generalization: If I got it right, the PM2 will allow
me to set negative values for line endpoints, and if that works right, it
will be a speedup, if the hardware can handle the clipping.

Thus I think it would be a mistake to disallow clipping negative values,
just because the Matrox card cannot cope with it. It might be a gain for
other cards that can clip negative values, so we shouldn't disallow that.

Comments ?

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =