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 <javali...@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 <javali...@cbfiddle.com> > Subject: <AWT Dev> creating images using native code > Date: August 11, 2015 at 5:36:55 PM PDT > To: awt-dev@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 > >
