[OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455 JLightweightFrame: support scaled painting

[Jim Graham]

That sounds like a good plan.  Hopefully the resulting webrev will be 
short and sweet and easy to verify.

We still leave on the table any convenient way for a developer to get 
auto-scaled-double-buffering without going through these same pains in 
their own code, but hopefully everyone relies on Swing to do the major 
portion of their (retina) double buffering...

			...jim

On 12/13/13 10:13 AM, 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
>