Re: Slimming down the drawing API.

[Fred Kiefer]

Hi Richard,

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 
> time
> rationalising the subset we provide/will provide.
>
> I don't think we should actually use any non-PostScript interface 
> between the
> 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 
at all.

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.

> implement
> different ways of drawing an NSBezier path and an NSImage, for 
> efficiency/simplicity)
> as I don't think there are any other areas where the data structures 
> concerned are
> 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 
> normally
> use anything other than a PostScript api internally - I'd like to go 
> over that
> 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.

Cheers
Fred