Le 28 févr. 08 à 01:12, Fred Kiefer a écrit : > Quentin Mathé wrote: >> Le 14 janv. 08 à 16:53, Fred Kiefer a écrit : >> >>> Two comments though. In the first two changes you are doing the >>> flipping >>> yourself. Wouldn't it be easier to call the method >>> fillHorizontalRect:withImage:flipped: with the last parameter set to >>> YES? It would be even better if Camaelong moved that isFlipped >>> parameter >>> one method up, but this is a larger change. >> >> What do you mean by one method up? Which method should get the >> isFlipped >> parameter? >> > This is more or less just rephrasing what I wrote in my September > mail. > Camaelon has one layer where it doesn't know about flipped status and > uses it again one layer below. It would be easier to know about > flipping > all the way through, but most likely you already fixed this.
Ok. I think Andreas initially fixed it by introducing - drawInRect:flipped: method in CLHBoxCompositor. I moved this new method to CLCompositor to allow all related subclasses to handle flipped coordinates. >> After checking Apple doc (Cocoa Drawing Guide), they suggest the >> following code on p. 35: >> >> [NSGraphicsContext saveGraphicsState]; >> >> NSBezierPath *clipPath = [NSBezierPath bezierPath]; >> [clipPath appendBezierPathWithRect: rect]; >> >> [clipPath addClip]; >> >> [NSGraphicsContext restoreGraphicsState]; >> >> So I would say Camaelon code is correct, even if it's probably >> better to >> use NSRectClip or +[NSBezierPath clipRect:] for such clipping. What >> do >> you think? >> > Correct yes, but using the shortest way to express what should > happen is > in this case also the fastest one. ok. Just out of curiosity, is it likely that Apple doesn't use these NSGraphicsContext methods in most of Cocoa drawing code but rather calls the underlying CoreGraphics functions directly? >> Shouldn't we also use NSGraphicsContext methods rather than >> DPSgsave and >> DPSgrestore? >> By reading NSGraphicsContext.m in GNUstep, I found that >> -saveGraphicsState and -restoreGraphicsState are managing a state >> stack >> in addition to call DPS functions. I don't understand why, aren't >> DPSgsave and DPSgrestore maintaining a state stack too? > > The stack of the gstates is in both cases used just the same. What is > different is that the code in NSGraphicsContext.m uses a stack for > graphics contexts on top of that. This is needed as soon as multiple > contexts get used. I see. >> A last question, why +[NSBezierPath clipRect:] doesn't call >> NSRectClip >> in GNUstep NSBezierPath.m? Apple documentation sounds to define >> them as >> identical, but I'm not perfectly sure though. >> > > clipRect calls PSrectclip and NSRectClip calls DPSrectclip which are > the > identical function apart from some Macro processing. The only > difference > is that the later also sets a new path, but this already gets done on > the GSGState level. Why not favor only one function like DPSrectclip and keep the other one only for compatibility reason? This part of the API could be a bit more clear imo. For example, no documentation is available on the following pages: - http://www.gnustep.org/resources/documentation/Developer/Gui/Reference/index.html - http://www.gnustep.org/resources/documentation/Developer/Gui/Additions/index.html (only CG functions seems to be provided when you read the doc). By publishing those functions and their related classes on the last page, we may know better which parts of the API can be used safely in the drawing code of applications. >> Thanks for your september mail that was really helpful to figure >> out the >> proper fixes. >> > > You are welcome, I am just glade it was of use after all. Well I should have done it earlier, sorry for having been so slow. Thanks, Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
