Don't offset views rendered on top of snapshots

[fynngodau]

This PR fixes view rendered on top of the map during snapshots being offset incorrectly.

For no discernible reason, in mapbox/mapbox-gl-native#9179 (comment), it was introduced that a view that is a child of the map view is rendered 10px to the right, 10px to the bottom of its original position.

This introduces visual glitches already visible in the screenshot linked above. Therefore, this PR removes this offset.

It also fixes any other child views a user may choose to put on a map (the use case I have in mind is custom info windows).

In the following screenshots, bottom is live map, top is snapshot – it is the "Snapshot Activity" in the sample app:

Before	After

[ovivoda]

@fynngodau for the same purpose you could also call

public static Bitmap mergeBitmap(@NonNull Bitmap background, @NonNull Bitmap foreground, float left, float top) just use 0f and 0f for left and top

I do not think this change is really necessary.

[fynngodau]

@ovivoda It is true we could also change the place in the maplibre code that calls mergeBitmap(Bitmap, Bitmap) to instead call mergeBitmap(Bitmap, Bitmap, float, float) directly. However I have chosen to change this function instead because rendering a snapshot appears to be the only context in which it is called, and 10px times 10px offset really isn't a sane default here anyway.

[ovivoda]

@fynngodau my point here is backwards compatibility. If someone uses the old mergeBitmap method and does some maths based on that, the new behaviour will mess it up. This is why, I think that, if there is a method to achieve same thing, we should not change the old behaviour.

[fynngodau]

@ovivoda I see. Yes, considering that this API is public, it does consist a breaking change in some sense, though I doubt that any user of the API actively wants exactly a 10x10 shift of the image and therefore I would still prefer to change the default here, and announce the breaking change in a changelog.

I'll push a commit that leaves the method intact but changes the documentation so that users are aware of this behavior.

[ovivoda]

@fynngodau alright. If you think that this is really a must let's do it like this please:

• mark current method as deprecated
• create a new method to merge bitmap with no shifts

Then we have the best of both worlds and after some time/versions we can actually remove the old method.

But removing it now, or change the behaviour, I do not think it is expected in a library.

[fynngodau]

@ovivoda Seems like a good idea. What would be a good method name for such a new method?

[ovivoda]

this is a tough one @fynngodau

maybe mergeBitmaps will work

[fynngodau]

👍, I've added a new commit for this.

[ovivoda]

it looks good! Thanks @fynngodau