<AWT Dev> Fwd: creating images using native code
damjan.jov at gmail.com
Tue Aug 18 17:13:35 UTC 2015
Unofficial comment here.
If you're referring to the fact that doing anything but constructing
DataBufferInt with a size and without an array, and calling any method
that returns the internal array, marks the data as untrackable:
then no, the only workaround might be to access the internal array
using reflection, but I am not sure that will result in the correct
Is pixel by pixel setElem() really a bottleneck?
On Tue, Aug 18, 2015 at 6:48 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> Is this the right place to ask this question?
> Unless my concerns are misguided, is seems that a public API is needed to
> replace uses of the internal API.
> Begin forwarded message:
> From: Alan Snyder <javalists at cbfiddle.com>
> Subject: <AWT Dev> creating images using native code
> Date: August 11, 2015 at 5:36:55 PM PDT
> To: awt-dev at openjdk.java.net
> I am currently creating images with data provided by native code by
> capturing the data in an int array then using that array to construct a
> DataBufferInt which is used to create a WritableRaster which is used to
> create a BufferedImage.
> That seems to work fine, except that looking at the code it appears that the
> buffer is considered untrackable, which sounds like a bad thing. Does that
> in fact prevent caching the image in a GPU, for example?
> If so, is there a good way to create a cacheable image?
> The solutions I have found so far all wind up processing the pixels one at a
> time at some point, as far as I can tell, which should not be necessary.
> I’m wondering why there is no way to simply declare that the buffer will not
> change in the future.
More information about the awt-dev