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