Big images (straight from the camera on certain Apple devices) are reported to be incompletely processed by canvasResize, and memory exhaustion is suspected to be the culprit.
Looking at the code, I see it basically delegates the bulk of the work to HTML canvas drawImage(), which is a good idea (performance-wise -- quality is another matter).
As a side effect, images smaller than 1024x1024 get exactly one call to drawImage() (plus the value added of all your code -- workaround bugs, etc).
In a search for ways to reduce memory consumption, I'm considering reducing tile size (currently set by var d = 1024 in source) to e.g. 512. It would mean 4 times more calls to drawImage(), which should not be a problem, but a 4 times smaller tmpCanvas (256kpixels instead of 1Mpixel), hence reduced memory consumption.
What do you think about this attempts to reduce memory consumption ?
Is the value d=1024 carefully selected with reasons to keep it that way (e.g. browsers known to optimize algorithms for this size) or not ?
Big images (straight from the camera on certain Apple devices) are reported to be incompletely processed by canvasResize, and memory exhaustion is suspected to be the culprit.
Looking at the code, I see it basically delegates the bulk of the work to HTML canvas
drawImage()
, which is a good idea (performance-wise -- quality is another matter). As a side effect, images smaller than 1024x1024 get exactly one call todrawImage()
(plus the value added of all your code -- workaround bugs, etc).In a search for ways to reduce memory consumption, I'm considering reducing tile size (currently set by
var d = 1024
in source) to e.g. 512. It would mean 4 times more calls todrawImage()
, which should not be a problem, but a 4 times smallertmpCanvas
(256kpixels instead of 1Mpixel), hence reduced memory consumption.