Hi Lee,
> In short, why not? I'll do the work. GGI doesn't lose anything,
> it only gains.
Yes - but also in size.
> No need to respond. I know what the answer is.
Please don't take it personal. We decided to stop LibGGI growing at exactly
the current stage quite a while ago. The idea is, that LibGGI stays the
minimal set of operations that is required to get a fairly quick access
path for 99% of applications. This requires getting/putting pixels as a
last fallback measure, HLines for apps that do linewise updates , VLines
for those that do columwise ones (rare, but for some raycasting type apps
it might be the natural way) und Boxes for those that update full screens
at a time. The other common operations often used by GUI apps are FillBox
(Windows), DrawLine (Border elements, decorations) and CopyBox (scrolling).
That's a s far as we went.
I also sacrificed a function I had put in there, ggiDrawCircle (which was
pretty optimized), as it was really rarely used. It was nice for a few of
the demos, but otherwise pretty unused.
All that stuff is intended to go into extensions to keep LibGGI as small as
possible. Especially important for embedded system stuff some people here
use it for ...
> But that's my position and I'm sticking to it.
I see your point, but please consider putting it in an extension. You have
to admit, that the functionality is rarely needed. An extension can do
everything a LibGGI function can do, so nothing lost in putting it there
...
> > LibXMI
> I have only had a brief look at XMI. From what I have seen you have done a
> beautiful job with it and I will certainly take a closer look at it.
Please do so. Maybe this is where your function fits in.
BTW: Jon - I haven't looked at LibXMI for long. Is it a full extension
(rendering libs and all ?) If so, you might want to consider adding
a few utilizations of ACCEL_DRAWTRIANGLE to the kgi-command renderer of
it. Might make it rock on Permedia chips :-).
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
