[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we have convertTo/FromBase in view?
From: |
Quentin Mathé |
Subject: |
Re: Can we have convertTo/FromBase in view? |
Date: |
Sat, 25 Dec 2010 18:31:57 +0100 |
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.
- Can we have convertTo/FromBase in view?, Banlu Kemiyatorn, 2010/12/21
- Re: Can we have convertTo/FromBase in view?, David Chisnall, 2010/12/21
- Re: Can we have convertTo/FromBase in view?, Fred Kiefer, 2010/12/22
- Re: Can we have convertTo/FromBase in view?, Banlu Kemiyatorn, 2010/12/22
- Re: Can we have convertTo/FromBase in view?, Fred Kiefer, 2010/12/23
- Re: Can we have convertTo/FromBase in view?, Banlu Kemiyatorn, 2010/12/23
- Re: Can we have convertTo/FromBase in view?,
Quentin Mathé <=
- Re: Can we have convertTo/FromBase in view?, Quentin Mathé, 2010/12/25
- Re: Can we have convertTo/FromBase in view?, Banlu Kemiyatorn, 2010/12/25
- Re: Can we have convertTo/FromBase in view?, Banlu Kemiyatorn, 2010/12/25
- Re: Can we have convertTo/FromBase in view?, Quentin Mathé, 2010/12/25