[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slimming down the drawing API.
Re: Slimming down the drawing API.
Wed, 20 Feb 2002 00:20:20 +0100
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2
now that I was so happy that I may at least add one non-PostScript
interface method, you are taking that away again. Just joking.
Your mail really deserves a more serious answer.
Richard Frith-Macdonald wrote:
As Fred pointed out at the weekend, we have quite a few DPS functions
that we don't
actually use, as well as at least one PostScript capability that we
*will* need to
use, but don't have in the xgps backend.
We accepted a long time ago that we are never going to be able to
support a full
PostScript interface for all backends - so perhaps we should spend some
rationalising the subset we provide/will provide.
I don't think we should actually use any non-PostScript interface
front and back ends (with the exception of letting different backends
I totally agree that we need a well defined interface between those two
based only on methods on NSGraphicsContext, no further subclassing or
what so ever. But I don't quite see, why this has to be a
pseudo-PostScript interface, just because this happened to be most parts
of the defined interface on a NextStep machine. The problem being that
the basic PostScript would just provide us with a very powerful drawing
interface, so we always need some extensions. Some of this might come
from the DPS extension, but even there we would miss things we need.
Beside the limited functionality as a windows manipulating language
PostScript is also a bit clumsy to use. It is a stack oriented language,
where you push things on the stack to use them later on by poping them
again. When I first looked at the stack code in xgps I was surprised to
find that most of it did not work. So I fixed it, which is a shame now,
than otherwise it would be so much easier to proof that we don't use it
I would even add that I also think that most of the interface operations
we allow for must be somehow easily mapped to PostScript operations, as
we want to keep a PostScript back end and also need the ability to write
PostScript for printing. But this just requires a PostScript like
drawing model, not a PostScript interface.
different ways of drawing an NSBezier path and an NSImage, for
as I don't think there are any other areas where the data structures
sufficiently complex that conversions would be complicated or inefficient.
This might be true for the current functionality of GNUstep, but it will
no longer be true, if we try to provide a full OpenStep (or MacOSX)
interface. I know that you are not that familiar with the short comings
of the gui classes, but there is still a lot missing that could only be
provided by extensions to the interface to the back end, NSSound and all
those fancy view classes are examples.
Actually, I'm not wholly convinced that NSBezierPath and NSImage should
use anything other than a PostScript api internally - I'd like to go
issue again in some more detail if someone could explain to me.
So why did I want another interface for NSBezierPath? First of all, as
Nicola already pointed out, we want our users (that is the GNUstep
application programmers) to use the most high level interface that is
available for the task at stake. So when somebody is doing a direct line
drawing operation she should use NSBezierPath and not call the basic
PostScript functions. That way a program will run with GNUstep as well
as with MacOSX. But to get this we have to provide a fast
implementation of NSBezierPath operations. Currently when a user build
up a NSBezierPath and strokes it, that path gets decomposed and each
element is send over to the back end separately. For the xgps back end,
and probably for all non-PostScript back ends we will than reconstruct
that path there (once again as a NSBezierPath) and stoke this.
To make this faster I did request an operation to send over a
NSBezierPath to the back end as a whole. (Or if you prefer this,
separate operations to fill, clip, stroke etc. a path) Once again, the
only reason for this being the speed up. So if you don't like it, I will
won't do it, but I will point anybody that will be complaining about the
speed of our back ends to you.