Re: Working on new backend

[BALATON Zoltan]

On Wed, 2 Oct 2002, Alexander Malmberg wrote:
> Chad Hardin wrote:
> > The current situation split I have planned is so:
> > DirectFB: windowing system using directFB multi-app capabilities
>
> The 'server' part.
>
> > DirectFBlib: DirecFB based graphics and font rendering (very basic)
>
> The 'graphics' part. I would advise you to implement a server part with
> the XWindowBuffer interface and use back-art or back-gslib, though.

I agree. You should concentrate on the server part. The graphics parts can
be reused from other backends.

> [snip]
> > Has there been any discussion of creating a deeper hierarchy of directories
> > for the backend?
>
> No, because it makes no sense given the way things work. Different
> graphics (NSGraphicsContext implementations, in practice) do not need to
> be server-specific. The gsc/ code is used in xlib/, winlib/, and art/,
> and art/ can use both the x11/ server and the rds/ server (which isn't
> usable yet, and isn't in cvs). (If gslib/ uses XWindowBuffer like art/
> does, it will probably be easy to change it to use eg. rds/, too.)

The gslib backend is at the same level as gsc/, ghostscript's drivers
correspond to xlib/ and winlib/. The gslib backend currently uses a
generic ghostscript driver called 'display' that renders to memory buffers
so it is server independent. Currently the memory used is an XImage which
is created in the X11 specific part in a separate file that is easy to
implement for any server. I plan to change it to use the XWindowBuffer
interface added to x11 to get a shared memory buffer to render into for
performance once I find some time to work on it again. So it will be
easier to use other server parts if they support the same interface but it
should not be a problem currently either. Anyway a common interface to get
a (shared) memory buffer from the server is useful for graphics
implementations. (This was in my proposal for backend server-graphics
interface I've sent some time ago.)

Regards,
BALATON Zoltan