gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal. Looking for feedback, interest, etc.


From: BALATON Zoltan
Subject: Re: Proposal. Looking for feedback, interest, etc.
Date: Fri, 6 Sep 2002 18:43:38 +0200 (MEST)

On Thu, 5 Sep 2002, Chad Hardin wrote:
>   The main thing I?d like to do is to create a new, non-X11 backend which
> uses a common postscript based imaging model.  Instead of X11 I want to
> interact with the kernel framebuffer in a similar fashion as OS X does.

The gslib backend I'm working on is very similar to this. The gslib
backend is mostly independent from X, the X dependent part is separated in
its own file and all it does is copies memory to the display. If you want
to port it to fb you have two options. Implement the X specific part using
fb or write an fb driver for ghostscript and use that. (The former is
easier, the latter is more difficult but gives you more control to use
optimised implementations such as hardware accelerated line drawing and
filling. I'd suggest to start with the first option.)

To make GNUstep work with fb however you would also have to write a
backend server for fb to handle events and windows. The backend server is
where the functionality of the WindowServer and DisplayManager is
implemented. Currently servers for x11 and win exist.

> lib would only be able to render to an in memory pixmap, nothing more.  That
> way, the exact same code could be used for both printing and the display.

Ghostscript has drivers to render to memory (among others). The gslib
backend is currently also uses such a driver, the "display" device which
is system independent. This will be the default operating mode but I plan
to modify the X11 ghostscript driver later to make it work with GNUstep.
This will give better remote display performance and hardware acceleration
where available such as the second option above. Ghostscript also has
drivers for printers so high quality printing can also be supported.

> By using shared memory the graphical result can be transferred to the
> display or a printer device interpreter/converter.

I currently do not use shared memory in the gslib backend. It could be
done in the X specific part but I think it should be implemented in the
x11 backend server instead. I hope the XShm code will be moved from
backart to the backend x11 server.

>   I?ve been reading the PS and DPS references and I know creating a PS
> interpreter is no easy feat.  The VM is complicated and the generic path
> based graphics is no joke to code (especially to make it run fast).  I?m not
> proposing a completely new code-base be started, rather, I was thinking of
> grabbing the GPL ghostscript and ?cutting and pasting? it into this new
> project.  AFAIK the license allows this (feedback?)

Before trying to imlement your own library you should look at ghostscript
first. It can be compiled as a shared library and used as an embedded
interpreter in other software. The gslib backend however does not do this.
It has no interpreter, instead it uses the ghostscript imaging library
(gslib) directly (what the interpreter also uses) to avoid the overhead.

>   Since the PS lib would be very generic, it is plausible it can be used in
> the x11 backend as well.  Is anybody else interested in this?
> More specific, is anybody interested in helping?

I'd ask the same question. It looks like the gslib backend is similar to
what you have in mind but it is not finished yet. I'm working on it but I
have limited free time so some help would be very nice. I'd suggest you to
have a look at it and see if it fits your plans. The catch is that it is
not yet usable as font handling is still missing. I'm working on this but
I cannot tell how much will it take to implement it. Instructions and
pointers can be found at
http://mail.gnu.org/pipermail/discuss-gnustep/2002-August/017073.html
Comments are welcome.

Regards,
BALATON Zoltan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]