Re: Can we have convertTo/FromBase in view?

[Quentin Mathé]

Le 25 déc. 2010 à 21:11, Banlu Kemiyatorn a écrit :

> On Sun, Dec 26, 2010 at 3:05 AM, Banlu Kemiyatorn <address@hidden> wrote:
>> On Sun, Dec 26, 2010 at 12:33 AM, Quentin Mathé <address@hidden> 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.