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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev