<AWT Dev> Fwd: creating images using native code

[Damjan Jovanovic]

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:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/awt/image/DataBufferInt.java
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
behaviour.

Is pixel by pixel setElem() really a bottleneck?

Damjan

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.
>
>   Alan
>
>
>
> 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.
>
>  Alan
>
>