[osx] Fix scaling issues when painting dirty areas

[martincapello]

The SkiaWindowOSX::paintGC was using integer units to calculate the scaled size portion of the source image that had to be updated. This caused that for odd rect sizes when using an even scale the rendering was offset by one pixel (one sub-pixel actually when scale was 2 for instance).

For reference: this issue was reported in a comment from another issue: aseprite/aseprite#5095 (comment)

Steps to reproduce the issue:

1. Having the following settings:
   Screen scaling: 200%
   UI elements scaling: 100%
2. Snap the main window to the top of the screen (the right corner should do it as well).
3. Unsnap the window by dragging it from its title bar (this is the "interesting" part...unsnapping the window will make it have an odd size, not the size it had before snapping).
4. Move the mouse cursor around the bottom of the editor and the top of the timeline. You should see how the rendering of some lines of the window is offset by 1 pixel (1 subpixel actually because we are using 200% screen scaling).

[dacap]

It works 👍 it looks like a new bug on macOS with this new feature to dock windows on each side (should we report to Apple?). I'll merge this fix, probably we should investigate the possibility to round the window size to a multiple of m_scale in a future, just like in WindowOSXObjc initWithImpl:spec: (but it's not urgent):

laf/os/osx/window.mm

Lines 73 to 77 in 18a7d47

	// Align the content size to the scale, because macOS give us the
	// chance to create the frame with any size, then the
	// contentResizeIncrements stablish a delta from this initial size.
	contentRect.size.width = int(contentRect.size.width / m_scale) * m_scale;
	contentRect.size.height = int(contentRect.size.height / m_scale) * m_scale;

[martincapello]

It works 👍 it looks like a new bug on macOS with this new feature to dock windows on each side (should we report to Apple?).

Yeah, it seems like a macOS bug to me too...maybe we should report the bug, will see if I can make a simple demo app to reproduce it (no laf, just using appkit and objective-c).

I'll merge this fix, probably we should investigate the possibility to round the window size to a multiple of m_scale in a future, just like in WindowOSXObjc initWithImpl:spec: (but it's not urgent):

Actually I had tried another fix that was like that and worked as well. I just went for this one because I realized that the SkRect::MakeXYWH parameters were of float type. But yeah, I'm fine with using any approach that works.

[dacap]

Probably Apple will not consider this a macOS bug as they can change the window size with with whatever size they want (just like the window is created), and the contentResizeIncrements is just a way to specify how much increment/decrement the window size: https://developer.apple.com/documentation/appkit/nswindow/contentresizeincrements

But it doesn't work as a "multiple of" specifier for the content/client area width/height as we are using the our "scale" field (this is a constraint from our side only).

[martincapello]

Probably Apple will not consider this a macOS bug...

Well, then maybe it doesn't worth it to report it...so I won't do it, unless you say so.