Re: Cairo and ISO C++

Bill Spitzak <[email protected]>
Newsgroups gmane.comp.lib.cairo
Message-ID <[email protected]>
That is just making it more complicated which does not help.

I suspect some backends are more efficient if they clear the path as 
part of the fill/stroke. I was hoping that saying that you cannot modify 
the path after fill/stroke would allow such backends to work while 
preserving the path. But now I am not so sure, especially if the backend 
is PostScript.

Ray Gardener wrote:
> On 1/14/2014 3:10 PM, Bill Spitzak wrote:
>>
>> PRESERVE PATH
>>
>> I would have filling/stroking a path not clear the path, but instead 
>> put cairo in a state so the next moveto/lineto will clear the path. 
>> This will allow fill, stroke to work like users expect, and by 
>> removing the "preserve" calls reduce the size of the api.
>>
> As a general design rule, it's nice if functions have minimal or no side 
> effects. There is an explicit way to clear the path: newpath.
> 
> You could add a new function: setpostpaintbehavior(enum { 
> clearcurrentpath, preservecurrentpath });
> 
> By default, the post-paint behavior does what it currently does, which 
> is to clear the current path after fill/stroke. But the user can change 
> it to preserve the path. The "preserve" APIs could then be dropped. The 
> arg is an enum so a CLEAR_PATH_ON_NEXT_MOVETO could be added too, if you 
> want that behavior.
> 
> Ray
> 
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.