[OpenJDK 2D-Dev] <AWT Dev>  Review Request: JDK-8029455 JLightweightFrame: support scaled painting
james.graham at oracle.com
Tue Feb 11 19:45:17 UTC 2014
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...
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).
> 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.
>> 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,
>>>>>> 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
>>>> 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...
More information about the 2d-dev