Re: Can we have convertTo/FromBase in view?

[Quentin Mathé]

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 <address@hidden> 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.