[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: High-DPI screenshot
From: |
Quentin Mathé |
Subject: |
Re: High-DPI screenshot |
Date: |
Sun, 17 Apr 2011 13:51:16 +0200 |
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.
- High-DPI screenshot, Eric Wasylishen, 2011/04/12
- Re: High-DPI screenshot, Fred Kiefer, 2011/04/13
- Re: High-DPI screenshot, Eric Wasylishen, 2011/04/13
- Re: High-DPI screenshot, Fred Kiefer, 2011/04/16
- Re: High-DPI screenshot, Eric Wasylishen, 2011/04/16
- Re: High-DPI screenshot, Fred Kiefer, 2011/04/17
- Re: High-DPI screenshot,
Quentin Mathé <=
- Re: High-DPI screenshot, Eric Wasylishen, 2011/04/19
- Re: High-DPI screenshot, Quentin Mathé, 2011/04/20
Re: High-DPI screenshot, David Chisnall, 2011/04/13