From: Thomas Tanner <tanner@gmx.de>
  To  : Peter Danielsson <peter.danielsson@era-t.ericsson.se>
  Date: Sat, 05 Sep 1998 12:33:02 +0200

Re: targets for libggi2d

Peter Danielsson wrote:
> 
> Hi!

 Hi

> I wonder if you could explain to me how libggi2d is
> supposed to work? Or rather tell me if my guesses are
> correct.

 Of course :)

> I'm working on a graphic frontend to a small linuxbox
> (Due to lack of memory and disk to swap to we will not
> be able to run X (actually what we are building is
> similar to the itsy (www.research.digital.com/wrl/itsy)))

 Wow! Sounds very interesting.
 
> We have finally decided to use GGI for graphics. But
> since there is no way to run two ggi program simultaneously
> (that I know of - and without X) I am in the process
> of writing some kind of window system, where each window
> is a GGI-visual (OK maybe not the most effective system,
> but it has some advantages). This means that I have to write
> a new target for libGGI and a server that handles the actual
> drawing. If I've understood things correctly libGGI2d could
> sort of hook onto an existing target and provide better
> performance by using native methods.
> 
> Is this view close to how things actually works? and if it is,
> how do I write the target for libggi2d?
> 
> Peter

 Yes. You can write a libggi2d driver which accelerates functions
 supported by your target while the rest is emulated by libggi2d.

 libggi and its extensions such as libggi2d have normally no drawing
 functions built in but they call the functions of the driver or 
 some helper libraries which are stored in a function table.
 Whenever you open a drawing API on a visual some "stub"
 libraries are loaded (the names and number of libraries may differ, 
 but it's always the same order), which set the entries in the function table:
 1. generic-stubs: tries to emulate most of the API functions using
    very few functions (e.g ggiSetPixel) or a fallback API (e.g. libggi)
 2. a framebuffer dependent stub-library (e.g linear-8):
    optimized functions for a specific framebuffer layout
 3. additional helper libraries, such as generic-color
 4. the driver library: native (accelerated) functions.
 The names are determined by the display target driver, 
 which outputs so called "suggest-strings".
 A kgi driver could, for example, output: 
 "generic-stubs", "linear-8", "matrox-8"
 Extensions append their suffix to the suggest strings 
 to get the names of their stub libraries.

 In libggi2d the things are much more complicated than just 
 setting functions in the function table at loading time.
 Since libggi2d has a rather complex rendering pipeline 
 (clipping, antialiasing, textures, operators, ...)
 it wouldn't make sense to store all functions optimized 
 for different pipelines in a single function table.
 Instead of this libggi2d calls each driver/library to set 
 optimized functions for the current graphic context (GC)
 whenever the GC is modified (e.g by ggi2dSetOperator)
 A more detailed (though a little bit outdated) description of 
 this scheme can be found in the repository (lib/libggi2d/doc/Internals)
 I'll write a sample driver for SVGALib that you can use as template.
 
 As for the windowing system there's already a library 
 for such things: libGWT
 The authors are: Tristan Wibberly <twibberley@llamacom.com>
 and Rodolphe Ortalo <ortalo@laas.fr>
 
 The only thing you would have to write would be a shared memory
 target, which lets other applications draw on an exported visual.
 (I hope that your chip has a MMU) The window server would set 
 GGI_DISPLAY to e.g "display-shared:0x0222FA3A" ... and so on.

 Good Luck!

-- 
Thomas Tanner -----------------------------
email: tanner@gmx.de tanner@ggi-project.org
web:   http://home.pages.de/~tanner
cool:  www.ggi-project.org  www.gnustep.org