I found that second sample is not clear.
The idea is that if application has a lot of polylines (coastline or
something like this). Software usually using these ones has to transform the
lines according scale, orientation and view position. There can be 100.000
or more lines. But software usually does not have to scale and rotate these
lines every time. After rotation and scale, we can get a lot of lines ready
to out after adding some xy displacement values. So we can get benefit from
using hardware clipping and hardware line drawing. If GGI deny it software
like I described has to use own clipping.
Best Regards, Dmitry
>>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? 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) I'd like to
>>hear it.
>Many applications have 2d or 3d transformation before access to any draw
>functions. That transformation usually does not care about negative values.
>I can give a some navigational system with map inside as sample
>There are two way:
>1. clip before transformation
>2. clip after
>Sometimes 1 is better and only I can do in case of performance suppositions
>(sample big filled polygons). We just have to be sure that our result for
>the clipped area will be inside of our screen after transformation. What is
>wrong. We lack hardware clipping.
>Second item is good in case of we have hardware clipper (sample we have to
>draw a lot of lines). I need clipping from GGI library only to access to
>hardware. If I have to clip by myself there is no place to assumption that
>GGI has clipping and I lose acces to hardware clipper.
Best regards, Dmitry Semenov
