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. > > >> 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. But most likely views are pretty static. In some 3D > engines I found they often cache local to base transformations, with > mark dirty scheme. > > Banlu
Sorry, clicking send too fast, And I think for redrawing, most view aren't rotated or scaled (these properties existed already), and with those no multiplication are required. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
