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. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
