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
|