Christophe Rhodes csr21@cam.ac.uk writes:
Comments?
Here's an implementation of a more minimal, less invasive change. SET-MEDIUM-GRAPHICS-STATE goes away and is replaced by :AROUND methods on REPLAY-OUTPUT-RECORD the various graphics state mixin types, which use WITH-DRAWING-OPTIONS to bind dynamically the various bits of graphics state that they need. The uses of SET-MEDIUM-GRAPHICS-STATE in incremental-redisplay then boil down to setting the stream cursor position; the uses of MEDIUM-GRAPHICS-STATE there actually should just retrieve the cursor position, but I haven't altered that in the source.
Then GSharp, which specializes DISPLAYED-OUTPUT-RECORD (a specified class, unlike STANDARD-DISPLAYED-OUTPUT-RECORD, where all of these changes have been occurring) can itself remember the bits of medium state it needs (ink and clipping-region), and then the effect of the graphics state of each output record is dynamically contained to its own replay, and not any other records'.
And all this lets me put up screenshots like http://www-jcsu.jesus.cam.ac.uk/~csr21/gsharp-with-working-repaint.png.
I have tested a couple of other applications with this (the Address Book still works!) and nothing seems terribly amiss. I'd like a sanity check, though, and maybe consideration of whether having analogues to displayed-output-record-ink would make sense. (I think it would, and in fact I think that with this change the various bits of graphics state /are/ attached to the output record).
Cheers,
Christophe