[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pixel-aligned autoresizing
From: |
Eric Wasylishen |
Subject: |
Re: Pixel-aligned autoresizing |
Date: |
Wed, 6 Jul 2011 03:19:35 -0600 |
Hi Fred,
On 2011-07-06, at 2:32 AM, Fred Kiefer wrote:
> On 05.07.2011 22:15, Eric Wasylishen wrote:
>> Hi,
>>
>> In the last month I was looking in to making GS's drawing output
>> match cocoa exactly, in particular, getting rid of rounding in the
>> backends.
>>
>> One of the problems I encountered is GS can give autoresizing views
>> fractional positions/sizes, whereas when Cocoa autoresizes views it
>> only ever sizes them to pixel-aligned rects. The problem with GS's
>> current behaviour is it will make UI elements blurry if we get rid of
>> rounding in the backend.
>>
>> Attached is a preliminary patch* which switches to Cocoa's behaviour.
>> I wanted to ask for feedback as to whether this is a reasonable patch
>> to apply.
>>
>> The patch has to do a bit more than simply adding rounding to -
>> (void) resizeWithOldSuperviewSize: (NSSize)oldSize, because if we
>> just round _frame, we will lose track of where a view originally was.
>> I add a new ivar _autoresizingFrameError which stores the difference
>> between the rounded _frame, and what _frame would be without
>> rounding. The only slightly messy bit of the patch is that any parts
>> of the code that modify _frame directly should also set
>> _autoresizingFrameError to {0, 0}.
>
> One result of this patch will be that calling -frame after a call to
> -setFrame: with fractional coordinates will return a different result
> than the one we provided.
Hm, that shouldn't be the case. -setFrame: still sets the _frame ivar to
whatever it is passed, and -frame still returns _frame unmodified.
The only difference in -setFrame:'s behaviour (and all other methods that
modified _frame directly) is that it will have the side effect of clearing the
_autoresizingFrameError, but this isn't directly observable. The value of
_autoresizingFrameError is only used inside -resizeWithOldSuperviewSize: to
compute the new size.
> I just checked on Cocoa and as expected this
> isn't the case there. For this reason I am strongly against this patch,
> although I fully support the goal you are aiming at. We need to come up
> with a different way for it.
Assuming there isn't actually a problem I'm overlooking, the patch probably
needs to add some extra documentation explaining what is going on :-)
> Basically wee need to ensure that all drawing operations that are
> initiated by the gui drawing code get pixel aligned. Somebody will have
> to test whether this is true for all drawing operations, that is, when I
> use an NSBezierPath with fractional coordinates to draw into a NSView,
> will the result be blurred? I expect this to be the case, which means that we
> cannot put the pixel alignment directly into the backend, but need to do it
> in our own drawing code. The next level would be the functions in
> Functions.m. What will be the result if we feed them with fractional
> coordinates? And so on to determine the level of intervention that is needed.
Agreed. Most of that work is already done in GSTest's PixelExactDrawing-test,
and you can toggle between what GS is rendering and a screen captures from OS
X. Drawing with NSBezierPath and fractional coordinates should produce blurred
output. Same for all of the ops in Functions.m which I've checked.
>
>> [*] One thing I would change in the patch is instead of rounding
>> using floor(), I would call -centerScanRect: so that the
>> pixel-alignment takes in to account the transformation matrix of the
>> current view.
>
> Good point, this method seems to be better suited. Are you aware of the
> warnings in that method?
Yes. One thing we could do is simply return the passed rect unmodified if
[[NSGraphicsContext currentContext] isDrawingToScreen] is NO. Not sure if Cocoa
does that but it would make sense to, I think.
-Eric
- Pixel-aligned autoresizing, Eric Wasylishen, 2011/07/05
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/06
- Re: Pixel-aligned autoresizing, Jens Ayton, 2011/07/06
- Re: Pixel-aligned autoresizing,
Eric Wasylishen <=
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/06
- Re: Pixel-aligned autoresizing, Eric Wasylishen, 2011/07/07
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/07
- Re: Pixel-aligned autoresizing, Eric Wasylishen, 2011/07/08
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/08
- Re: Pixel-aligned autoresizing, Eric Wasylishen, 2011/07/08
- Re: Pixel-aligned autoresizing, Fred Kiefer, 2011/07/08
- Re: Pixel-aligned autoresizing, Philippe Roussel, 2011/07/09
- Graphics Rounding (was Re: Pixel-aligned autoresizing), Eric Wasylishen, 2011/07/09
- Re: Graphics Rounding (was Re: Pixel-aligned autoresizing), Fred Kiefer, 2011/07/10