Index: [thread] [date] [subject] [author]
  From: MenTaLguY <mentalg@geocities.com>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Thu, 27 Aug 1998 20:42:04 -0500 (EST)

Re: LibGGI2D, LibGGI3D and targets

On Wed, 26 Aug 1998, Jon M. Taylor wrote:

> 	I've been looking at how to start coding some LibGGI3D display
> targets, and in the course of exploring the existing LibGGI targets I saw
> that LibGGI2D doesn't have any targets per se.  All the targets are part
> of LibGGI itself.  Why is this?  IMHO, the targets, to the extent that
> they handle 2D framebuffer rendering, should be part of LibGGI2D. 
> Otherwise, I either have to go ahead and create separate LibGGI3D display
> targets (which gives LibGGI2D and LibGGI3D inconsistent structure) or I
> have to add LibGGI3D code to the LibGGI targets (which adds bloat
> unnecessarily).  The demos in lib/libggi/demos all seem to be 2D-oriented
> - do they belong in lib/libggi2d/demos?  Please help me understand this.

additional support for extension APIs (i.e. ggi2d and ggi3d) is loaded by
the target, according to what the target's idea of the underlying junk is.

Last I looked, it was set up such that if the stub "blah-foo-stub" was
loaded into the visual by the target, indicating some specific support, when
the 2d API was activated for that visual, LibGGI itself would look for a
"blah-foo-stub-2d" and load that.  How exactly does that work with the new
extension mechanism?

-=MenTaLguY=-

Index: [thread] [date] [subject] [author]