[win32] Cleanup image wrappers #2036
Conversation
HeikoKlare
force-pushed
the
win32-cleanup-image-wrapper
branch
from
5de2869 to
0786ad3
Compare
akoch-yatta
force-pushed
the
win32-cleanup-image-wrapper
branch
2 times, most recently
from
616acf8 to
2e9c992
Compare
| return imageProvider.getImageMetadata(zoom); | ||
| } else { | ||
| ImageData resizedData = getImageData(zoom); | ||
| ImageData newData = adaptImageDataIfDisabledOrGray(resizedData); |
There was a problem hiding this comment.
This was removed at the place where this code was moved to. Was that intended, i.e., it is sufficient to only do the adaptation at the remaining places?
There was a problem hiding this comment.
I think, it was not completly correct. I want to cover all places, where scaled variants of an ImageData is created and those could be not adapted. My latest commit removed an unnecessary call (calling place already does it) and adds one call.
There was a problem hiding this comment.
Thank you! It looks fine now. I didn't find a path that is not covered properly. Still, we might think about if we could further improve this in the future as the it's quite difficult to understand where this adaptation logic has to be placed and why it is correct right now. And since it's hard to test, it may easily be removed at some of the placed accidentally, leading to errors that are not easily perceived.
But for now, it's fine as is.
There was a problem hiding this comment.
Yes, I agree. We should try to better streamline ImageData creation/scaling in Image
akoch-yatta
force-pushed
the
win32-cleanup-image-wrapper
branch
from
2e9c992 to
7502fc6
Compare
This commit refactors Image in the win32 implementation as Image#imageProvider is final and always != null now. With this the handling and creation of new handles and ImageData was unified.
HeikoKlare
force-pushed
the
win32-cleanup-image-wrapper
branch
from
7502fc6 to
3accd93
Compare
|
Version increment check is failing for infrastructure reasons and no further version bump is required here. |
This PR refactors Image in the win32 implementation as Image#imageProvider is final and always != null now. With this the handling and creation of new handles and ImageData was unified.
Relies on #2027 being merged first and includes this commit because of that.