Adam Fedor wrote: > 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. > > The gsave/grestore operations are rather expensive. Where possible we should try to avoid them internally. Even without this there are different ways we could achive the same results. This is one of the things that makes programing such an interesting and hard job, there are always more than one solutions and you have to go for the best of them. I would prefer the solution, where we set all the parameters before we start any drawing operation. This is different from the current winlib implementation, there each Gstate operation is preseded by the mostly unneeded resetting of all parameters. I know that this differs a lot from our current drawing model, that is why I wanted to discuss the change first. > > >> 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? > The GSSendBezierPath: allows for the fast transfer of the coordinates of a path, what is missing is the fast transfer of the properties of a path. This would for all but the ps backends set the path to a copy of the provided path. This can only work if the path parametes are applied before each drawing action. And this is why I opt for the new drawing model for all the gsc backends.
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
