On Wed, 20 Sep 2000, Lee Brown wrote:
> 1) I'll wrap up that KGI documentation I started.
> This should be done by Sunday.
> 2) While looking at the GGI API it struck me that there is ggiPutHLine,
> ggiGetHline, ggiPutVline, ggiGetVline. Why isn't there a ggiPutLine
> ggiGetLine?
Well, the historical reason is that the old 8514/A 2D acceleration
feature set, which in mostly the same format was used in all the old S3,
ATI, etc video chipsets, is what the core LibGGI drawing functions were
architected around. Newer 2D hardware achitectures (Matrox, nVidia, 3Dfx)
tend to have similar 2D featuresets as well. Thus, Hlines, Vlines, box
drawing, rectangular blits, and a few others I forget were thus almost
100% guaranteed to be present when _any_ hardware accelerated target
environment was used, and since LibGGI's drawing functions were supposed
to be the minimum standard, that's what was chosen.
Another reason is that Hlines and vlines behave the same when
using hardware accelerated drawing operations and software drawing. That
is, you always know exactly which pixels were drawn, and where, in both
cases. We do assume that readback is always possible and consistent,
which in the case of hardware with no framebuffer like and i810 or Voodoo
will _not_ behave consistently, but that's another issue. "Lines"
(generic bresenham lines) will generally not give you this same exact
correspondence between accelerated and unaccelerated drawing, due to the
nature of the bresenham algorithm and different round-off errors from the
CPU to the video chipset, and thus from the GGI perspective they are in a
different class of accelerations. That means that, in general, they
should be implemented in a separate "advanced 2D" extension library.
LibXMI is what we have as far as an "advanced 2D" library right
now. It supports wide, dashed, styled and/or textured lines in the spirit
of X11 - WAY more complex than simple one-color hlines or vlines, and thus
also WAY more complex to properly implement in both unaccelerated and
accelerated fashion. This implies that the internal interfaces
("intrafaces") which libggi and each extension implements differently,
should be the primary determinant factor in deciding which types of
hardware and software drawing operations should be placed into the same
extensions. From this perspective, there's really no such thing as "2D"
or "3D" or "filtering" or "windowing" types of hardware accelerations -
there's only drawing operations which tend to be found together in
clusters when hardware accelerated, and which tend to have similar
properties like reversibility, consistency of operation between HW and SW
drawing, and complexity.
> Is this already implemented?
LibXMI does crazy mad line drawing |->. help yourself.
> It strikes me that this could
> be useful and there doesn't seem to be any way for the user to implement
> these routines themself.
They should be implemented in an "advanced 2D" extension library.
That's what LibXMI is.
> It is quite doable (even I could implement
> this). Maybe I'm missing something here.
Have a look at LibXMI. There's no rule that say that the XMI way
is the only way to implement "advanced 2D" drawing operations, but it is
here now and works.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
