GGI Extensions, LibGG the new core and more

Author : GGI-develop
Date : 2005-04-17
Revision : 1.2
Revision date : 2005-10-11

Section I

LibGAlloc and above

It's the goal of GGI 3.0 to have libgalloc and the 4 lowlevel extensions libggiovl, libggiblt, libggimisc and libggibuf on top of libgalloc.

libggiovl: provides the use of overlay resources like hw-cursor, hw-sprites, yuv-window, etc. All of it is only available through hw acceleration. Current state: API and API documentation is in place, concept partially implemented

libggibuf: overloads libggi's drawing primitives and extends them with any kind of buffer - i.e. alpha, z, texture, stencil, etc. Current state: API for alpha and z-buffer and API documentation is in place, alpha and z is implemented and usable

libggiblt: provides generic all-purpose blitting operations using the batchop technology: Current state: concept is in place, API documentation partially available

libggimisc: already in place and usable. Needs to be adapted to use libgalloc once libgalloc is ready for end-users.

Section II

LibGII and libGGI

1) libggi/libgii decoupling: we need to drop libgii dependency from libggi. It doesn't really make sense to mix the twos, or to impose libgii as an event subsystem.

This idea has been kicked around forever. Use GII as an extension which routes gii_events through ggi_visuals using the visual as a source/sink for events (like is done now, but optional). This way people could use GII completely independently of GGI, and it would also be possible to remove the ggi*Event*() functions from the GGI core.

2) libgg / libgii decoupling: they are in the same tree, but actually libgg could live by itself. This is also needed if the first point is accepted.

3) In libgii: as an interface, the input module API should draw the line more clearly between libgii internals and driver interface. I see the explicit dependency on select(2) and as a breach in the abstraction. In fact, there should be two include files: ggi/gii.h for applications and ggi/gii-input.h for input modules. And the second one is not internal IHMO. About static modules, there is work ongoing in the ggbundle branch.

4) Separate mode setting from drawing in libggi, allowing to use libggi for mode negotiation but something else for drawing. One way to look at it would be to transfer the core of libggi to libgalloc, a visual being something for which we can negotiate a graphic mode (or other features). This lead me to view the whole GGI project as a set of interfaces, that can be dynamically provided to an opaque handle, (visual, input...). Specific implementations for these interfaces are attached at run time on the handle via modules. Interfaces can more or less cooperate, but do not necessarily depend on each other. Thus, the current 'look-and-feel' of libggi with libgii dependency, would be obtained in a much more generic way by attaching the GGI and the GII interface to the same handle (called independently, a visual or an input). This API attachement scheme could be provided by libgg.

Section III

Improving the 2D API

Any serious 2D will require the use of an extension anyway. The original LibGGI 2D drawing fuctions were based around the hardware accelerations of an older S3 chipset, which in turn was based on the IBM 8514/A chipset. To get an idea of what a good, feature-rich 2D API looks like these days, have a look at DirectDraw. I gather that people are separating the act of drawing something in 2D (ROPs, BOB abstraction, etc) from the objects to be drawn (boxes, textures, lines, text, etc) via the LibGGIBlit extension these days.

I like the idea of "letting a thousand flowers bloom" and doing many, many, MANY GGI extensions of various styles - some old, some new, some experimental, some 'standard' (whatever that means). It is more work to maintain all the targets for all those extensions, but this is good as it promotes code reuse within the targets.

Section IV

Other proposals

  • GStreamer LibGGI extension. GStreamer contains most of the concepts I had envisioned for LibGGI3D, and it looks to have been extremely well done. The Basic idea is to use GStreamer modules as components of a 3D rendering pipeline to build a retained-mode rendering fabric. Rendering flows would terminate on a GGI library API call to do the actual rendering. The only question is, would GStreamer be fast enough to do decent 60+ fps rendering of any sort of complex graphics model in 3D?
  • What happened to LibGWT? A decent z-order window manager was one of our priorities, way back when, and it was mostly done IIRC. Could we bring it back?
  • LibGGIGL is also missing. There wasn't much there, but it was a nice way to get GL working in the GGI framework without having to use Mesa (for Win32 in particular).