Re: High-DPI screenshot

[Eric Wasylishen]

Hi Fred,

On 2011-04-16, at 5:40 PM, Fred Kiefer wrote:

> Hi Eric,
> 
> I am trying to understand the patch you send.
> 
Cool, thanks for taking the time to look over it.

> I can understand the NSScreen bit. There you allow to change the 
> userSpaceScaleFactor via an user default setting, which is a nice thing to do.
> 
> The changes to the GSStandardWindowDecorationView are actually bug fixes, we 
> used the frame where we should have used the bounds, but up to now this 
> difference didn't show. This should go in, no matter what or when the rest of 
> your patch makes it in.
> 
> The change to GSWheelColorPicker seems similar. But here I don't quite 
> understand what goes on. Why would a view need to know what the underlying 
> base size is? Is this because we want exactly one colour for each underlying 
> pixel on the screen?

Yes.

> This sounds reasonable, but I don't like the idea of it. One of the benefits 
> of the OpenStep drawing code is that it tries to be independent of the 
> resolution. What other views would need this?

I don't think there's anything wrong with it in terms of philosophy. 

Here is my reasoning: the original code was rendering a bitmap because there is 
no vector-graphics drawing method that can draw that colour wheel. Instead of 
rendering an arbitrary size, say 1000x1000 pixels - which would work fine, it 
uses the view bounds size as the dimensions in pixels, as a performance 
optimization. The problem with this is that if we introduce a scale factor 
which makes the final size of the view in device pixels larger than the 
user-space dimensions of it in points, the bitmap we rendered will end up being 
scaled up using interpolation, making it blurry.

So my change here just makes the bitmap as large as it needs to be so it won't 
have to be upscaled later in the drawing process, but no larger. It's not 
really introducing a dependence on resolution that wasn't already there, it's 
more of a quality hint. The old code still had a resolution dependence in this 
sense, but it assumed a 1:1 scale factor. The important thing is that the old 
code would still look correct, just blurrier.

So no views including GSWheelColorPicker need the change, but if there are 
places where bitmaps are generated which use an assumption that user-space is 
equal to device space to optimize the pixel size of the generated image, they 
can benefit from this change too (but only to get sharper output - they 
wouldn't require it.)

Unfortunately, due to a bug in the implementation of NSImage drawInRect: 
methods, the change in GSWheelColorPicker doesn't actually produce sharper 
output. I think it's due to the size of the intermediate surface which is 
created but I haven't looked in to it in detail.

> The biggest part of the patch are the changes to the NSView conversion 
> methods. If I understand these correctly the change is that for an argument 
> of nil we use the identity transform instead of the transform of the windows 
> decoration view. Is this correct?

Yes, I was fixing that. I probably rewrote the methods more than necessary but 
I think they're clearer to read now.

> 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.

> 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. :-) 

> The core of the patch is the change to GSWindowDecorationView. Here we decide 
> where the actual scaling happens. I)s it between the window and the screen, 
> the decoration window and the content view or between the screen and the 
> physical device. I still haven't made up my mind here, but we should try to 
> get a behaviour close to what Apple implemented.

On OS X 10.6 when you set a scale factor (in QuartzDebug) the frame of the 
topmost view in a window (their equivalent of GSWindowDecorationView) increases 
while the bounds rect stays the same. They also mention that NSWindow's frame 
is always in physical units/pixels, if I recall correctly. So, my patch should 
be compatible with Apple's implementation.

Cheers,
Eric

> Cheers
> Fred
> 
> 
> On 14.04.2011 00:21, Eric Wasylishen wrote:
>> Hi Fred,
>> Yes, it implements the userSpaceScaleFactor concept.  I attached the current 
>> patch if you want to have a look.
>> 
>> I had to re-implement -[NSImage 
>> compositeToPoint:fromRect:operation:fraction:] because it is supposed to 
>> respect the scale factor.  I just compute an appropriate transformation 
>> matrix and call -drawAtPoint:fromRect:operation:fraction:. This is also nice 
>> because it reduces the number of code paths. It will need some testing, but 
>> it seems to work fine for me (I verified it with Quentin's test program from 
>> https://savannah.gnu.org/bugs/?func=detailitem&item_id=27782).
>> 
>> --Eric
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2011-04-13, at 1:47 AM, Fred Kiefer wrote:
>> 
>>> The screen shot looks really great. Is this an implementation of the
>>> userSpaceScaleFactor concept found in NSWindow and NSScreen? Nikolaus
>>> Schaller implemented that in mySTEP a few years ago and I always wanted
>>> to copy that over to GNUstep but never got around to do it.
>>> 
>>> On 12.04.2011 21:34, Eric Wasylishen wrote:
>>>> Here's a screenshot of a patch I'm working on which scales the UI for
>>>> high DPI monitors - I think it's pretty cool :-)
>>>> 
>>>> It was surprisingly easy to implement. The actual scaling is done
>>>> simply by changing the bounds and frame rects in
>>>> GSWindowDecorationView (no changes in -back, and it works with
>>>> cairo/art/xlib). You can set an arbitrary scale factor via a
>>>> GSScaleFactor user default. Other than that, there were just a couple
>>>> of bugs to fix to get it to work (and still some bugs remaining, but
>>>> it's at least usable.)
>>>> 
>>>> I'll commit this after the upcoming release.
>>>> 
>>>> Cheers, Eric
>> 
>