Re: Pixel-aligned autoresizing

[Fred Kiefer]

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

> [*] 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?