Floating-point logical sprite image dimensions

[1ec5]

On HiDPI screens, the logical dimensions of a sprite image can be non-integral.

Fixes #2198.

/cc @incanus @friedbunny

[friedbunny]

Awesome that you tracked this down, fix works. Adding some decimals in iosapp's marker image code is enough to confirm:

diff --git a/ios/app/MBXViewController.mm b/ios/app/MBXViewController.mm
index 6380406..61d39b8 100644
--- a/ios/app/MBXViewController.mm
+++ b/ios/app/MBXViewController.mm
@@ -368,7 +368,7 @@ static UIColor *const kTintColor = [UIColor colorWithRed:0.120 green:0.550 blue:

     if ( ! image)
     {
-        CGRect rect = CGRectMake(0, 0, 20, 15);
+        CGRect rect = CGRectMake(0, 0, 20.5, 15.5);

         UIGraphicsBeginImageContextWithOptions(rect.size, NO, [[UIScreen mainScreen] scale]);

[jfirebaugh]

I'm suspicious of the float ⇢ integer conversions that will be happening after this change here and here. We should probably review our handling of physical/logical dimensions at a higher level. Always using integer pixel dimensions plus float pixel ratio makes the most sense to me, but I haven't thought about it a lot.

[1ec5]

The upshot is that without floating point logical dimensions (expressed in "points" in iOS), you can't have an odd width or height after multiplying by the pixel ratio.

[1ec5]

The padding in allocateImage() would seem to inoculate this particular change from any ill effects. SpriteAtlas::getPosition() is only used to render backgrounds, fills, and lines, so it doesn’t come into play when assigning images to markers. I realize that introducing the concept of non-integral dimensions to just SpriteImage is problematic in the long run. However, this seems like a workable stopgap fix for #2198 while we consider more disruptive changes such as eliminating the concept of pixel density outside the renderer.

[bleege]

Also related to Android via #3031

[jfirebaugh]

I'm working on a different fix along the lines of #3008 (comment), and build on the new PremultipliedImage class.

[bleege]

@jfirebaugh Sounds good! Do you have a ticket or branch that we can link to so that we make sure this gets addressed / tickets closed in the iOS and Android bindings when it's ready?

[jfirebaugh]

@bleege: #3164.