Re: High-DPI screenshot

[Quentin Mathé]

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.

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?

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;
        }
    }

The downside of this change is that it's going to make -compositeToPoint: 
slower, but not in a way that matters I think.

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 :-(

Cheers,
Quentin.