Re: High-DPI screenshot

[Fred Kiefer]

Hi Eric,

I am trying to understand the patch you send.

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

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?
This change is probably related to the change in _rebuildCoordinates, 
which I didn't quite understand.

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.

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.

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