Le 25 déc. 2010 à 21:11, Banlu Kemiyatorn a écrit : > On Sun, Dec 26, 2010 at 3:05 AM, Banlu Kemiyatorn <[email protected]> wrote: >> On Sun, Dec 26, 2010 at 12:33 AM, Quentin Mathé <[email protected]> wrote: >>> >>> NSView conversion methods requires both the receiver view and the argument >>> view to be in the same view hierarchy (the Apple doc states they must >>> belong to the same window). >> >> I kinda use misguiding word, different hierarchy means they are not in >> the same branch, only share an ancestor.
Ah ok I understand. >>> It's unclear to me why GNUstep uses these two matrices 'fromWindow' and >>> 'toWindow' per view rather than just having a 'superviewBoundsToFrame' >>> matrix and a 'frameToBounds' matrix. Most UI toolkits seems to use this >>> approach in their view hierararchy equivalent. I think it's more easy to >>> debug geometry issues this way, and the drawing code would do less >>> conversions when the view hierarchy is redrawn (based on what I remember >>> from the NSView drawing code the last time I looked at it). Some cases >>> would be more costly like invalidating drawing areas, but based on some >>> tests I have done, this is negligible even with a complex view hierarchy >>> and many invalidations, when compared to the time spent in the geometry >>> conversions during a recursive redraw. >>> Am I overlooking something or are there some special advantages with the >>> current approach? >> >> Not sure I understand this correctly, I think if you didn't store >> fromWindow, toWindow and store conversion and inversion to superview, >> then to convert a point you may need to keep multiplying a few >> superviews until it reach the root, which could be a few matrix >> multiplications. Exactly. That's what would occur when calling -setNeedsDisplayInRect: to invalidate a view area, given that invalidated areas are stored in the base coordinate space. Btw the two matrices I suggested can probably be merged into a single one. When I replied, I thought that some NSView API might require to convert from the frame space to the superview or from the frame space to the bounds space, but this seems unnecessary. >> But most likely views are pretty static. In some 3D >> engines I found they often cache local to base transformations, with >> mark dirty scheme. View hierarchies are quite shallow. More than 4 levels between a view and the window content view is pretty rare. Which means a recursive conversion up to or down from the base coordinate space doesn't cost much. > And I think for redrawing, most view aren't rotated or scaled (these > properties existed already), and with those no multiplication are > required. Yes. Quentin. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
