On 12/12/13 2:33 PM, Sergey Bylokhov wrote:
On 12/12/13 11:27 PM, Jim Graham wrote:
The only real difference here is that BufferedImages have multiple
definitions of width and height. For VolatileImage objects there is
no view of the pixels so the dimensions are the layout size and the
expected renderable area and the returned graphics is pre-scaled. For
BufferedImage we can do all of that, but the dimensions have the added
implication that they define the valid range of values for getRGB(x,
y) and grabbing the rasters/data buffers/arrays and digging out pixels
manually.
If it were just getRGB(x, y) we could simply do a 2x2 average of
underlying pixels to return an RGB value, but I don't think there is
any amount of workaround that we can apply to make the digging out of
the rasters and storage arrays work for those who manually access
pixels... :(
But I am talking about OffScreenImage(or we can add new one), which is
not public so we can try to block/change operations in our code. Not
sure that our backbuffers leaked to the users.
OffscreenImage is a subclass of BufferedImage so if a developer ever
gets their hands on it then they may get confused by our use of the
getWidth/Height. But, if there is no way for them to get a reference to
it, then we can play games internally.
This will not help us with the return value of getCompatibleImage(),
though, which is specified to return a BufferedImage so we are somewhat
restricted in any use of logical dimensions there.
Also, if we are entirely managing the buffer internally, then we have
the option to just use a regular BufferedImage. We don't need any extra
magic if we render it with drawImage(x, y, w, h) since the "logical" or
"real" dimensions of the image have no impact on the results there. If
it is double-sized then those pixels will fit into the appropriate space
on the destination without any need to special case them in SG2D...
...jim
