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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
