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

[Anton V. Tarasov]

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).

Ok, you're still against those "conditional return values" :) I already 
tried to convey my thoughts describing the reason why I couldn't simply 
throw them away. But Ok, let's do it eventually, then look at the new 
version and judge it...

>
> One thing to keep in mind, though, is that Windows appears to allow 
> non-integer scales so I think we should not assume integer scale 
> factors in whatever new API we create...

I just sticked to the type of the scale factor returned by 
SurfaceData.getDefaultScale() which was int.

Thanks,
Anton.
>
>             ...jim
>
> On 2/10/14 3:37 PM, Jim Graham wrote:
>>
>>
>> On 2/10/14 6:11 AM, Anton V. Tarasov wrote:
>>>> On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
>>>>> In SG2D, the drawHiDPIImage, for instance, makes a call to
>>>>> op.filter(img, null); where the img is expected to return its layout
>>>>> size. That's why I still prefer to use the setReturnLayoutSize
>>>>> "switcher", in order not to go deep into the 2D rendering code, 
>>>>> casting
>>>>> here and there to OffscreenImage and calling getLayoutWidth/Height.
>>>>
>>>> Would we expect one of these images to have the BufferedImageOp
>>>> version of drawImage be used on it?  (It could happen if we ever leak
>>>> the object into developers hands, but I'm not sure if that can happen
>>>> or not - I'm pretty sure we don't use those Ops internally ourselves,
>>>> do we?)
>>>
>>> We don't use it internally. Originally, I had an option in the fix with
>>> which a developer could create a HiDPI BufferedImage. Then, I
>>> implemented the last SG2D.drawImage method which didn't have hidpi
>>> support, and created a 2D test for it. In the test I drew some 2D
>>> primitives into a HiDPI image, using a BufferedImageOp transform. So, I
>>> just tested the ability to use it externally.
>>>
>>> In the current version of the fix there's no option to get a HiDPI 
>>> image
>>> from the outside, so this code is not really used. I can eliminate 
>>> it if
>>> we think we don't need it in the nearest future.
>>
>> It might make sense to leave it in for now.  I'm not happy with that
>> design conceptually in the long term, but I don't think there is a 100%
>> pure/simple/obvious solution to the issues we are facing and it's not
>> really hurting anything in the short term...
>>
>>              ...jim