gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI/back changes in CVS


From: Alexander Malmberg
Subject: Re: GUI/back changes in CVS
Date: Wed, 13 Jul 2005 20:09:18 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]