Re: bundlelisation of the backend

[Fred Kiefer]

Nicola wrote in his mail:
> Doesn't this make the gui and the backend strongly coupled and difficult
> to understand ?

To put that straight for once: Our backend is strongly coupled to the
gui. We use gui data structures everywhere in here, and even subclass
them and sometimes rely on their internal structure. On the other hand,
the gui tries to avoid to be strongly coupled with the backend. It only
calls a few functions and a lot of methods on NSGraphicsContext. Sorry,
not even this is the full truth, this is done for the xgps backend,
where the DPS and PS functions are turned into method calls, for the
xdps backend these are directly mapped to the corresponding DPS
functions. This decision will have to be changed, if we want to use a
common gui for all sorts for backends. Than we will have to use either
of those two ways, getting a small performance penalty on the other
backend.

How does this relate to the problem of moving the NSXXX functions into
the gui, implementing them by operations on NSBezierPath and adding
faster support for the setting of a Bezier path? Not at all, as far as I
can see. The backends would only use the documented interface on
NSBezierPath, which is what the xgps backend is doing already. So there
would be neither more nor less coupling between them.

> 
> I understand the psw optimization - for the four or five nearly-basic but
> non-really-basic PS operations/functions which we use extensively in the
> gui, we provide a single psw file which gets compiled into a high speed
> function.  This compiled function is quicker because all the PS calls get
> merged and compressed together (am I right ?).  Anyway - the optimization
> is localized to the how the single function is internally implemented.  
> Instead, creating a NSBezierPath, setting the path inside it, then passing
> the path to the backend which accesses its internals to find out what it
> has to draw seems to distribute the optimization across libraries...  And
> to tie the internals of NSBezierPath and the backend...  But I think I am
> missing something as from my description I don't understand how would that
> (which creates an object, sets the path inside it, and then reads again
> the path elsewhere, draws, then destroys the object) go quicker than
> calling the PS functions directly in sequence.
> 

Again I don't see the point, when I replaced the old implementation of
the path operations in the xgps backend by one using NSBezierPath I did
not only get a lot of additional functionality. The new implementation
was even faster (As shown by GSBench, which only uses some direct PS
calls). This although I did not spend much time to optimize the
implementation of NSBezierPath (Perhaps Nicola could find some time for
this, he is really great at this) An implementation using an object does
not have to be slower than a lot of function calls, if done the right
way. For the xgps backend this is obvious, as this already uses a
NSBezierPath object, so setting one would just involve a copy assignment
and all the operations before that would now happen on a local Bezier
path instead of being tunnelled to the one of the gState. For the xdps
backend this will depend on the way we are able to implement the setting
of a Bezier path. And as I really don't understand the technic of the
psw files, I can only speculate that this will be rather efficient.

> The ideal design is that the backend consists of twenty or thirty basic C
> functions (to map, unmap windows, manage events, set up graphic contexts,
> draw lines, copy images etc) which you need to implement.  The easier, the
> simpler the better.  Once you have done that for your platform, it just
> works.  It would be nice to make it really simple - pure C.  If we were
> able to reach that point, gnustep-gui would be quickly ported everywhere.
> 

I thing this is the real difference. You see the the backend as only a
few C functions, and I would like to see it as a complex object oriented
piece of software on its own. And not only from it internal structure,
where this has been true for a long time now. Also from its interface to
the gui. Yes, there should be only a few well chosen methods that the
backend should have to implement, but this may and should take more
complex arguments as they do now. Currently the interface is dictated by
what DPS supports as data types. So we cannot even pass on a NSString to
a show method (Thereby loosing all the benefit of Unicode before we get
to the display). I think this has to change.
We should allow the interface to the backend to use objects as complex
as we need them. This would result in the xdps backend to need a bit
more implementation, but would simplify all the other backends. This is
no rejection of the PostScript operators we are currently supporting,
but for example it is the only usable way I see to implement the user
path PS operations.
We have to talk plain on this: Our current backend implements only what
is needed for the most basic graphical applications. It is great for
this, no question. But if anybody would try to implement anything more
complex with our current PS drawing interface, she would have to fail.