Le 24 déc. 2010 à 00:35, Banlu Kemiyatorn a écrit : > http://picasaweb.google.com/lh/photo/Vdp1gDf5VJF53jYsp2R9q3NLiCC_XFo2gzTr5JH_OUA?feat=directlink > > What I meant was that between (A) and (B), what should be the result > of conversion? > From (B) which will only use convertRectFrom/ToBase:, we just convert > red rect to green base rect then green base rect to blue rect but the > result will be larger then (A) > Been thinking more, I think we should produce (A) and to so it may be > already better to export affine transform to the base coordinate, > or we could just convert 3 points of the given rect. > > What's the result on OS X?
I haven't tested it on Mac OS X, but I agree that (A) sounds more correct. > On Thu, Dec 23, 2010 at 8:26 PM, Fred Kiefer <[email protected]> wrote: >> Yes, there is definitely a lot of room for optimisations here. I don't >> think that these extra computations are needed, but I didn't fully >> understand your mail, so I may be missing a point here. >> >> If anybody wants to address this issue, could you please also have a >> look at _rebuildCoordinates? The use of the global "flip" isn't thread safe. >> >> Am 22.12.2010 20:01, schrieb Banlu Kemiyatorn: >>> If we rely fromViews: methods on fromBase: et al, should we eliminate >>> the need to query a matrix from target view since they already have >>> native matrix to/from window stored? >>> Or is it better for rect conversion between 2 views with different >>> transforms so the result will enclose the target view's rect (ie. w/o >>> converting 3 points)? Or is that not necessary and the result should >>> just enclose the target's convertRectToBase: one, ie. I am not sure >>> why this is important if they are in different hierarchy. 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). 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? Cheers, Quentin. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
