Re: GUI/back changes in CVS

[Fred Kiefer]

Hi Alexander,

thank you for that feedback and more important: Great to have you back here!

Your comment on PSGsave and PSGrestore is correct. The problem here is
that we only know in the GState that we are going to draw a pattern
image, while the PSGsave and PSGrestore operations should be applied on
the context level. Not sure, if we should decorate every fill operation
with a save/restore combination.

You are propably correct about the drawToPoint call. Its just that this
fails on xlib sometimes that I didn't want to use that method,

Cheers
Fred


Alexander Malmberg wrote:
> Fred Kiefer wrote:
>>Fred Kiefer wrote:
>>>What I was planning to do was add a simple (and of course slow) pattern
>>>drawing mechanism for the gsc classes and perhaps overwrite this with a
>>>faster one for the xlib backend.
> [snip]
>>        [colour_pattern compositeToPoint: NSMakePoint(x, y)
>>                               operation: NSCompositeSourceOver];
> 
> I think this should be -drawToPoint:fromRect:operation:fraction: in
> order to handle transformations correctly; would have to check the PLRM
> to be sure about pattern semantics, though.
> 
> [snip]
>>All of this works fine. Of course EOFill is currently not supported, but
>>simple to do (would require a call to DPSeoclip instead of DPSclip). And
>>the clipping is what stops me from merging this code into CVS. As I need
>>to change the clipping, and restore it afterwards, I could either
>>implement this separately for each backend and not share any code or
>>implement that clipPath method, used in the current implementation, for
>>all backends. As this method is also not that easy, I could fake it by
>>storing the current clip path in another slot of the GState (and keep
>>the EO state within this path, as we need that as well when reseting the
>>old clip). But perhaps somebody out there has a better idea for this?
> 
> PSgsave/PSgrestore are the only portable methods for saving and
> restoring the clipping path, and I'd suggest using those. The current
> clipping path is the intersection of all paths passed to PSclip/PSeoclip
> (since the path was last reset, etc.; also, note that the filling rule
> merely specifies how the path to be intersected with the clipping path
> should be interpreted, the clipping path doesn't have any such
> property), so for a backend to be able to return the clipping path as an
> actual path, it would have to be able to compute arbitrary bezier curve
> intersections, and that's a nasty problem.
> 
> - Alexander Malmberg
> 
>