Hey Quentin,
On 2011-04-17, at 5:51 AM, Quentin Mathé wrote:
> Hi Eric,
>
> Le 17 avr. 2011 à 04:10, Eric Wasylishen a écrit :
>
>> On 2011-04-16, at 5:40 PM, Fred Kiefer wrote:
>>
>>> This change is probably related to the change in _rebuildCoordinates, which
>>> I didn't quite understand.
>>>
>> In _rebuildCoordinates, there was a special case which made the assumption
>> that the topmost view in a window has the identity transformation matrix
>> (bounds = frame). With my patch that is not necessarily true anymore, so I
>> had to rework the method to remove that assumption.
>
> On this topic, NSView might need to call _rebuildCoordinates more often that
> we do. For example, suppose -isFlipped is switched to YES, then a point or
> rect conversion method is called, shouldn't _rebuildCoordinates being called
> if wasFlipped doesn't match isFlipped? I haven't tried it, but I suspect Mac
> OS X takes in account -isFlipped change in various cases we don't cover such
> as conversion methods. In our case, a redraw is necessary before the flipping
> change is fully taken in account.
>
Hm, good point. Do you know if a view is allowed to return different values
from -isFlipped during its lifetime? It doesn't seem too useful to me.
My rewritten conversion methods now call [self _matrixFromWindow] rather than
(possibly) calling [self _rebuildCoordinates] and then reading the ivar
directly, so they are less fragile if we make changes in the future.
> A better approach would be to eliminate _rebuildCoordinates method, but that
> would require to change the way we handle transformation with the two
> matrices (to window and from window), to do it in a more traditional way with
> a matrix that expresses the frame in the superview bounds, and a matrix that
> expresses our bounds in relation to our frame.
>
>>> The change on NSCachedImageRep seems fine to me.
>>>
>>> The biggest change is, I think, the one to NSImage. Here the central
>>> drawing method gets replaced. It seems that the change matches the Apple
>>> documentation, but we will need more tests to decide whether it matches the
>>> actual implementation. You already noticed that. If this really works we
>>> get ride of one of the drawing primitives which would make the backend
>>> interaction a lot simpler.
>>
>> I agree, it's a big change and will need testing. :-)
>
> Does -compositeToPoint: still work the same than on Mac OS X when you start
> to rotate the bounds or frame of superviews?
>
Yes, it seems to work correctly with rotation.
> Did you test all the backends?… For -drawInRect, there are two code paths
> -guiDrawInRect (emulated draw operation) and -nativeDrawInRect. iirc
> -nativeDrawInRect is used by Cairo and Windows backends.
>
> You have a infinite recursion case with -guiDrawInRect: it seems, because of
> the code below:
>
> if (delta == 1.0)
> {
> NSAffineTransformStruct ts = [transform transformStruct];
>
> if (fabs(ts.m11 - 1.0) < 0.01 && fabs(ts.m12) < 0.01
> && fabs(ts.m21) < 0.01 && fabs(ts.m22 - 1.0) < 0.01)
> {
> [self compositeToPoint: dstRect.origin
> fromRect: srcRect
> operation: op];
> return;
> }
> }
>
Ah, thanks for catching that! I simply removed that whole block because it
looks like an optimization.
I've tested on all backends except win32.
> The downside of this change is that it's going to make -compositeToPoint:
> slower, but not in a way that matters I think.
>
Agreed. I want to do some more cleanup on NSImage in the future.
> It's major pain to have support NSCopyBits and PSComposite() given all the
> complexity they create in the backend. Woud be nice to be able to remove
> then, but that's not going to happen anytime soon :-(
>
Yeah, I agree.
Regards,
Eric
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
