> > Hmmm - might be a problem with HW-Accel. Marcus - are these HW-acceled in
> > the matrox driver ?
> Yes.
O.K. - explains a lot.
> > If so and the problem is reproducible, could you fix
> > that behaviour ? It is important, that HW-acceled functions behave exactly
> > as defined by LibGGI standards.
> This is not defined anywhere, and I strongly believe this behaviour
> should be documented, not "fixed".
No. LibGGI relies on being able to draw lines exactly in the same way, no
matter what drawing engine is used.
> 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.
No. They should be either completely defined or completely undefined.
So we either document that giving negative values to any drawing function is
undefined or we make sure every function obeys them as appropriate.
>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.
> 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.
? You don't need to. This is what fallback rendering is for. Look at the
KGI layer. If a function is not implemented or cannot handle a given
situation, it will just fall back.
Do the same for Matrox. All it takes is is something like
if (x1<0||x2<0||y1<0||y2<0) return fallback_drawline(...);
Is it only the negative values that make trouble ? I suppose so, as Matrox
very probably has HW-clipping.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
