I thought this sounded familiar. I remember having the thought before,
but forgot that I actually did something about this already in another
part of the code.
Both of those sets of methods already exist and they are used in the
decora ImagePool object to avoid having to allocate a larger
Hi Johan,
That sounds like the fix then.
Note that there is another optimization issue here that could be
addressed in a follow-on - basically when a larger physical size is
allocated, then we could expand the content dimensions to match what was
allocated. We would possibly need a new
Yes, please. Just get Jim to code review it and you can push it to 9-dev
yourself, since you are a committer.
For JDK 8, you need to request approval to backport. If approved by me,
then you can push it to 8u-dev.
-- Kevin
Johan Vos wrote:
Hi Jim,
Passing the contentWidth to the update()
Hi Jim,
Passing the contentWidth to the update() fixes the problem as well, and if
the excessive memory is not needed (as in my proposal), this is of course
much better.
Can I create an issue and suggest the following patch (this is for 8, but I
can do a similar for 9)?
- Johan
---
I think I see the issue.
In the code that calls maskTex.update(...) it passes
maskTex.physicalWidth() as the scan stride of the buffer, but the scan
stride of the buffer is based on the content size, not the physical
size. Thus, the checkUpdateParams() method overestimates how many bytes
Hi Johan,
Notes in line below...
On 3/8/16 6:14 AM, Johan Vos wrote:
We got a number of bug reports (on Android and iOS) reported by developers
using large images:
java.lang.IllegalArgumentException: Upload requires 2475266 elements, but
only 1549938 elements remain in the buffer
at
