On Fri, 27 Oct 2000, Johannes Zellner wrote:
> On Thu, Oct 26, 2000 at 05:53:12PM -0400, Lee wrote:
> > On Thu, 26 Oct 2000, Martin Schulze wrote:
> >
> > > Not in the core lib according to Andreas and the others. But if you ever
> > > find some time off, then you certenly could investigate the principles
> > > of how hardware acceleration is beeing made available for the extension
> > > libs lib libxmi. Then you could add the function to libxmi or rewrite
> > > the existing one making use of acceleration whereever it is supplied
> > > by libggi's targets.
> >
> > No doubt triangles should be part of the API. On the Voodoo card box it states
> > how many tiangles can be generated per second. Where exactly it should fit in
> > is arguable.
>
> drawing filled triangles /is/ a graphics primitive.
> If you consider filled triangles not to be a graphics primitve
> you've also to remove filled boxes from the core.
<architecture rant>
Yes, it is somewhat arbitrary. But if we add triangles, it won't
be long before people will realize that about all you can usefully do with
flat-shaded triangles is use two of them at a time to render boxes, and so
then texturing and shading will also have to be added to do anything
useful with the triangles, and then people will want to do something
_really_ useful with the triangles like draw them in 3D, which means we
now have to modify the basic ggi_pixel datatype and possibly allow for
floating- or fixed-point coordinates as well, etc etc etc. You see the
slippery slope here, right? There isn't anything so simple as "just add
another primitive". Primitive types do not exist in a vacuum in
real-world uses, they are tied to many other types of graphics concepts,
and it does nothing but needlessly bloat the core LibGGI API to add only
part of the solution.
Your comment about the arbitrariness of including filled boxes and
not triangles from the core LibGGI API set seems a reasonable one (and we
have heard it many times in the past from many people), until you look at
the set of 2D accelerations found on common SVGA graphics cards, which is
where the LibGGI API set was derived from. Even such older 2D accelerated
graphics hardware systems like the Amiga's OCS chipset follows the general
"line, box, rectblit, cliprect" pattern. LibGGI only supports primitive
text output for debugging purposes, and HLines/VLines because most SVGA
chipsets also support those. Many legacy APIs which must be targeted by
GGI, such as Xlib or SVGAlib or DirectX, also hold to similar design
patterns.
This principle of commonality of function and abstraction as being
the basis for API design (OOP principles applied to C programming) makes
it a LOT easier to design the LibGGI API, as well as the various extension
APIs, so that they do not need bizarrely complex internal target
structures. Every additional thing that each API has to worry about is
magnified to each of its targets, and when you start to consider "helper"
targets it is easy to see how the whole hyper-modular and hyper-flexible
GGI system could spiral into umanageable complexity fairly easily. We've
managed to avoid that so far by keeping the core LibGGI API frozen for
three years or so and requiring people to add new stuff to extensions. It
seems to be working fairly well so far.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
