Re: gslib patch second version

[BALATON Zoltan]

On Mon, 8 Apr 2002, Adam Fedor wrote:
> I couldn't get gslib to compile with this. Errors attached.

Sorry, the default target in the makefile is broken. You have to type
'make STDDIRS; make libgslib.a' that should work.

> First it should not set window->ident as the drawable. The drawable is
> actually passed in DPSsetgcdrawable, or if you don't want to use that,

I don't like that for two reasons. One is desribed in the patch the other
is that DPS.refmanuals.CLX says the following about this function:

: 5.8 Using Custom Operators
:
: After the execution of a setXgcdrawable, setXgcdrawablecolor, or
: setXoffset operator, the following graphics state parameters are left in
: an indeterminate state:
:
: * The current transformation matrix
: * The clipping path
: * The transfer function Each of the parameters will either keep its
:   previous value or be restored to its initial value, but it is not
:   always possible to predict which.
:[...]
: For performance reasons, you should execute setXgcdrawable,
: setXgcdrawablecolor, and setXoffset as infrequently as possible. It is
: more efficient to capture a particular graphics state configuration as a
: gstate object and use setgstate to return to it than to use
: setXgcdrawable, setXgcdrawablecolor, or setXoffset to reestablish the
: configuration each time you need it. In addition, the graphics state
: indeterminacies described above do not occur when using gstate objects.

> you could set the drawable in contextDevice: to window->buffer (if it's
> non-zero, window->ident otherwise).

Yes, I have tried that, but unfortunately window->buffer is a Pixmap and
the gs x11 driver only takes a Window as it maps and tries to set event
mask on that. Moreover the gs x11 driver handles the backing store buffer
on its own. Is there a way to tell the backend server not to manage the
backing store or does it have to do that for some reason? If yes I'd have
to modify the gs driver. BTW, the gs x11 driver also handles Expose
rectangles itself, so there is no need to do that in the backend server.
Is it defined what exactly is the task of the backend server and what the
graphics part should do? We should find a way so that the backend server
and the gs x11 driver can cooperate.

> Now, probably ghostscript is writting into the main window, while the
> AppKit is trying to refresh from the drawable.

I think this is the main source of conflict now. For testing it would be
enough to force all windows to be unbuffered for now. Is there a way to do
that?

> Also, I know this may not be possible at this point, but I don't think a
> new device should be created every time that contextDevice: is called.
> I'm not sure how ghostscript handles that - it could have problems. The
> AppKit should handle perfectly using the same context for many windows.

The main problem is that the gs x11 driver closes and re-opens the device
when a new WindowID is set on it. This erases the window which is probably
not what you want. For this reason I chose to create a new device for
every window. Currently this is done for every context but the
contextDevice method should really check if there is already a device for
the window and should probably use that. I didn't bother implementing this
until we decide which is the right way.

> Perhaps stuff is not appearing in the right place because the CTM matrix
> needs to be inverted for X drawing (or does the X driver already take
> care of that?).

The gs x11 driver should initialise the CTM when opening the device to
establish the proper user coordinate system as needed by postscript. All
this is in gdevxini.c. I will debug this if we manage to solve the
currently more serious problems above.

Greetings,
BALATON Zoltan