Closed itlancer closed 3 weeks ago
This is an interesting one - I'm a little surprised that changing the quality doesn't help actually. But essentially, this is a problem caused by overflow of the matrix that's used to render the image onto the display. The combination of the downscaling plus the translation means that the matrix ends up overflowing/invalid, and the failsafe drops back to a standard matrix which means you just get the normal image scaling/location, viewed through the clip bounds.
There's an aspect of the scale that's resulting from the anti-aliasing setting (related to stage quality) which is why I might think it would work if stage quality is lower. We can look at workarounds but the obvious option is to redraw the scaled image to a smaller bitmap..
thanks
Issue still exists with latest AIR 51.0.1.1.
We can look again at this, I think we should be able to detect the overflow of the matrix.... which means our options would either be:
So we have a way of working around this, specifically for bitmaps, which will help to a certain extent. The issue isn't that the scaling matrix itself isn't invertible, it's the translation part which overflows. This is to work out which pixel from the picture should be drawn into which target pixel on the output: as the target pixel gets larger, when there is a big downscale value then the translation gets massive. When the code detects it's gone wrong (got too large to fit into the 32-bit value) then it resets the scaling matrix to just an identity matrix so you just get a window onto the large image.
We've updated this so that in these cases, when we detect the 32-bit overflow, we switch it into a 64-bit variable. If the value would have overflowed a 64-bit value, then it would still end up with the same problem (so a huge image, massively scaled down, positioned at a very large x value, could still hit this... but it would be rare!)
thanks
@ajwfrost
Still doesn't work with AIR 51.0.1.4. The same sample as in original post. Now actual result not as scrollRect
but display only top left corner of image.
Fixed with latest AIR 51.1.1.2. Thanks!
Problem Description
Loaded big image (2300x1500 pixels, for example) into small bitmap object (90x60 pixels, for example) cause incorrect render (it starts to work like
mask
/scrollRect
) when itx
coordinate more than about 1255 pixels (different from image to image). This is very old bug.Tested with many different AIR and Flash Player versions even with latests AIR 32.0.0.144 beta and AIR 33.0.2.330 with different Windows, macOS, Android and iOS devices, its architectures, build target and OSes versions.
Tracker link: https://tracker.adobe.com/#/view/AIR-4153130 Related issue: http://forum.starling-framework.org/topic/all-platforms-big-image-in-small-bitmap-object-render-problem
Same problem with all cases with any "big image". Changing
renderMode
in application manifest doesn't help. ChangingStage::quality
doesn't help. ChangingBitmap::smoothing
doesn't help. ChangingrequestedDisplayResolution
in application manifest doesn't help. Parent (DisplayObjectContainer
) that containsBitmap
object doesn't matter.Steps to Reproduce
Launch code below and move mouse (or touch) somewhere to the right side of stage (application screen). "Problem coordinates" seems depends on screen resolution, application window size, image resolution and some other factors. Application example with sources and example of image attached. big_image_bug.zip
Actual Result: Image incorrect render. It start to work something like![actual](https://user-images.githubusercontent.com/10899066/70085800-0d88f500-1622-11ea-9d00-78a8d58dd649.png)
scrollRect
and show only strange part of image.Expected Result: Correct image render.![expected](https://user-images.githubusercontent.com/10899066/70085780-0661e700-1622-11ea-8b59-157539fca836.png)
Known Workarounds
Bitmap::cacheAsBitmap=true
but it cause memory and performance issuesBitmapData
but it also cause memory and performance issues