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.