Re: NSBezierPath setLineDash

[Adam Fedor]

Fred Kiefer wrote:
> This is just one of the places where our current fontend backend 
> interface could need some improvements. My position here is that all the 
> PS interfaces to change any of the path drawing parameters should be 
> deprecated and NSBezierPath methods used instead (This does not make a 
> real difference, but would introduce the newer interfaces into our own 
> code). In the backend those parameters would also be held inside of the 
> current NSBezierPath (and of course changed, when a new path gets 
> selected). Each time a path gets drawn those parameters would be applied 
> again to the backend specific graphic context. It is easy to construct 
> situations, where this may be a bit of an overhead, but for well 

I'm not sure I understand how this would work, unless it's completly 
transparent to a developer using the DPS or Quartz interface, since it 
violates both those models. In some backends that have to construct 
everything about a path everytime a new one is drawn this might be ok. 
But at least in the xlib and gslib backends, there has to be some point 
at which there is an implicit gsave/grestore so that previous path 
parameters can be reset. Why can't this gsave/grestore be in the 
NSBezier Path itself? It seems like it needs to be, be definition, and 
it's just as much overhead and wouldn't require changing anything else.




> structured drawing code it would not make a difference. And if we add 
> the long discussed setPath: method for the graphic context, it may even 
> be faster.

There's a GSSendBezierPath: in NSGraphicsContext now. Is that what you want?

--
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                      | know how I hate the stuff.