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

[Anton V. Tarasov]

Hi Jim,

Please, look at the update:

http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5

Here I'm correcting the rect after the transform in SG2D:

2123         // In case of negative scale transform, reflect the rect coords.
2124         if (w < 0) {
2125             w *= -1;
2126             x -= w;
2127         }
2128         if (h < 0) {
2129             h *= -1;
2130             y -= h;
2131         }


The blit direction (dx, dy) remains transformed. Is this the right behavior from your perspective?


On 11.02.2014 23:45, Jim Graham wrote:
> Hi Anton,
>
> These comments are about future public API, but this current patch is about getting the mechanism 
> working behind the scenes.  I'm OK with proceeding with the current patch as it is (modulo the 
> review feedback I gave) to get the mechanism working for the basic back buffer behind the scenes, 
> but we will eventually want the applications to be able to create their own HiDPI intermediate 
> buffers in addition to the back buffer that we manage for them - and these comments below are 
> about how we eventually expose this mechanism to them in a future stage...

Thanks for the clarification. (Please, see below.)

>
>             ...jim
>
> On 2/11/14 10:10 AM, Anton V. Tarasov wrote:
>> Hi Jim,
>>
>> On 2/11/14 4:12 AM, Jim Graham wrote:
>>> Just out of curiosity, on a Mac there is support for @2x images where
>>> they get loaded and used (at half scale to preserve layout size)
>>> automatically for you.  In that respect, the added resolution is
>>> hidden from the regular APIs and the developer doesn't really have to
>>> deal with the meaning of "size" as it relates to HiDPI.
>>>
>>> But, when you buy into HiDPI for your rendering, it looks like their
>>> system requires you to ask them to calculate the proper extents for
>>> the back buffer to render it and you are supposed to render it into
>>> that rectangle (FX is calling convertRectToBacking and then using the
>>> bounds to control the eventual blit of the back buffers).
>>>
>>> If that is the case, then it looks like we have some precedence there
>>> to have them buy into HiDPI backing stores or compatible images where
>>> the images report their pixel sizes and they need to manage the
>>> display size directly (i.e. by using drawImage(x,y,w,h) as we do
>>> internally).  I think we could make it a little more friendly than
>>> their "convertRectToBacking" system, but it would mean we wouldn't
>>> have to pollute the getWidth/Height APIs with conditional return values.
>>>
>>> For example, if we added getLayoutWH() or getScaleFactor() to image or
>>> bimg, then the normal ways of constructing those objects would simply
>>> return objects where the answers were unscaled and unsurprising.  If
>>> they went out of their way to request one that was scaled, then those
>>> new APIs (available on all images, but not very interesting except on
>>> the specially constructed DPI-aware versions) would have new values to
>>> help them manage the scaled image.  Unaware code would simply see
>>> these as overly large images, but it would be up to the developer to
>>> manage hiding any HiDPI images from any code that they had not
>>> converted to be DPI aware (just as we are doing here with our internal
>>> Swing buffer).
>>

So, HiDPI BI won't be backward compatible (unlike VolatileImage's) in terms of behavior?

Thanks,
Anton.