Re: Pixel-aligned autoresizing

[Eric Wasylishen]

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