<AWT Dev> [OpenJDK 2D-Dev]  Review Request: JDK-8029455 JLightweightFrame: support scaled painting
Anton V. Tarasov
anton.tarasov at oracle.com
Tue Feb 11 10:10:48 PST 2014
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 awt-dev