Re: bundlelisation of the backend

[Nicola Pero]

> The other optimization is the usage of psw files for some button
> operations in the xdps backend. I am not sure how big the gain from this
> is, but I have another idea to get a similar optimization, and not only
> for predefined PS calls:
> 
> We could make better use of the NSBezierPath class, by adding a PS call
> to the backend interface to set a NSBezierPath as a whole. The backend
> could than process the data in the bezier path in its most efficient
> way, perhaps without those basic PS calls used now. For the xgps backend
> I know that this will be a lot faster. I don't know enough of the xdps
> backend to tell, how this should be implemented, but it looks like a
> better place for optimization to me.

Doesn't this make the gui and the backend strongly coupled and difficult
to understand ?

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.

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.

Probably to do that, we would have a general library-to-write-backends,
which provides all the rest of the backend code.  You just link your set
of C functions with this library, and you get a working backend.

All backends would be linked with this library.  Backends which can use
optimizations could override functions in this library when they link with
it.

Don't take me too seriously in this mail as I'm just friendly chatting
:-)  what I said is probably all crap.