Hi, Anton.
Please check performance w/o buffers too, to know the difference.
On 13.12.2013 22:13, Anton V. Tarasov wrote:
Summarizing your comments. We can't export a scaled version of a
BufferedImage in the bounds of the current API without violating the
spec. Unless a scaled BufferedImage is used internally, in which case
we are less constrained. Ok, let's try this approach. I searched the
code for all the cases of calling those factory methods I mentioned
which create (or may create) a BufferedImage:
Component.createImage(..),
GraphicsConfiguration.createCompatibleImage(..),
GraphicsConfiguration.createCompatibleVolatileImage(..). I found 19
cases, but only 3 of them matters (the cases in which JLF differs from
standalone Swing). These are double buffers creation in JViewport and
RepaintManager, and AbstractRegionPainter.getImage(). Plus 1 case when
we create a root BufferedImage directly from JLightweightFrame. It's
possible to replace them with internal versions of the factory methods
which will return a scaled BufferedImage.
Then, the suggestion to return layout bounds from a scaled
BufferedImage, and physical bounds from its BufImgSurfaceData (we
don't bother about getRGB for now) eliminates the need to translate to
layout bounds in SG2D and unifies the code.
So, I'm going this way...
Thanks,
Anton.
On 12/13/13 2:54 AM, Jim Graham wrote:
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
--
Best regards, Sergey.
