Re: Changes to graphic context handling

[Fred Kiefer]

Last night when working on this change I run into a very bad problem.
Not only does most code in GNUstep implicitly expect that there is only
one NSGraphicContext ever set (with the exception of printing, but we
need to talk about this later). The whole graphics model implementation
in GNUstep has a problem with multiple contexts.
When doing a composite from one graphic state to another we pass in the
gState number of the source and the graphics contexts looks that up in
its user object dictionary to get the actual gState object. Of course
this will only work, if this gState was defined within the same context,
as each context keeps its own dictionary.

There is of course a simple solution to this: Use a shared dictionary.
If we store the connection between the context and the gstate also
(either in the dictionary or in the gstate) this would even allow us to
also implement the method [NSGraphicsContext setGraphicsState:].
This change would surely break the NSDPSContext, but we all expect that
to be broken anyway.
How would this change reflect back on printing? Not too great, printing
is not concerned with the real gstates, it only needs the numbers to put
in the Postscript file. But does printing with different gstates work at
the moment? No, when we reference a gstate that was not generated during
the current print operation then this will fail. This is why the print
code in NSView does not use the gstate of the window. Any other drawing
code that uses a preprepared gstate (even that of a cached image
representation) will fail when printing.
There is another problem with pre-allocated gstates for views. When the
window changes its device (caused by a resize) then they wont get
notified. When we are lucky the coordinates will be affected and a
direct redraw of the view will recreate the gstate. This should happen
for most views as they get redrawn when the device changes. But when the
view is just used as a drawing source this wont happen.

One specific problem is with the NSImage methods drawAt methods that use
a cached representation to generate the actual image to draw. Looks like
I need to rething all of this once more. Just to remind you why I am
doing this change: With this in place it should be fairly easy to
integrate the Postscript and PDF generation from cairo.

Fred

Fred Kiefer wrote:
> I am planing to implement some serious changes to NSGraphicsContext and
> the way this class interacts with the rest of GNUstep and wanted to
> publish this plans first, so you may comment on them.
> 
> Currently GNUstep uses mostly just one graphics context, the one set up
> in NSApplication. Only for printing other graphics contexts get created.
> The idea now is to let each window have its own graphics context. There
> still would be the default graphics context owned by the NSApplication
> and the ones for printing. In addition, we may even have graphics
> contexts to draw into memory space.
> 
> Why do this? One reason is of course to follow the change that Apple has
> done for OS 10.4. With our current setup we could not implement many of
> the methods on the class NSGraphicsContext nor some on NSView. Another
> reason is to get rid of the strange way we currently set up the gstate
> of a window, but this is a rather private reason. :-)
> 
> The graphics context will be selected when ever a view does a lock
> focus. When this has happened everything will be as before, the context
> returned by GSCurrentContext() will be the one for the active window.
> The difference will only be when no view has locked focus. Then a
> default context will be returned by this function. This context will
> mostly be used by events. Drawing on the default context should be
> regarded as an error. This may be a difference to the current state,
> where this drawing is silently ignored.
> 
> Now, what is the real benefit of this change? It will allow us to
> implement drawing for PS, PDF and bitmap output more easily. Our current
> PS solution works to a certain degree, but it is incompatible to MacOSX.
> 
> If nobody opposes this change, I will go ahead with it.
>