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

[Anthony Petrov]

Hi Jim, Sergey, and Anton,

I'd like to revive this old thread and finally push this fix, which has 
been reviewed and approved on this mailing list back in February. The 
only additional change that I want to introduce, is the addition of 
default implementations for the LightweightContent.imageBufferReset() 
methods. This allows clients of the API (namely, JavaFX) to run with 
both the old and the new JDK w/o any changes or side-effects. Here's the 
updated webrev:

http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/

It literally only adds the default methods and doesn't make any other 
changes to the rest of the already reviewed code. I've tested this on 
both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX 
builds, and it works fine in all the cases.

The current plan is to push this fix to JDK 9, and then back-port the 
changes to 8u20.

--
best regards,
Anthony

On 2/21/2014 2:47 AM, Jim Graham wrote:
> Yes, approved.
>
>          ...jim
>
> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>> Jim, so this is ready for a push then.
>>
>> Thanks!
>> Anton.
>>
>> On 15.02.2014 5:01, Jim Graham wrote:
>>> I don't need to see an update for that.  I didn't read the entire
>>> webrev, but I looked at this one piece of code and if that was the
>>> only thing changed then I think that dealt with the outstanding
>>> issues...
>>>
>>>         ...jim
>>>
>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>
>>>>>
>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>> 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?
>>>>>
>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a multiply
>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>
>>>>>             ...jim
>>>>
>>>> Jim,
>>>>
>>>> Yes, this indeed results in different byte code instructions (imult &
>>>> ineg). Just for curiosity I did some measuring which showed
>>>> negatioation
>>>> worked 10% faster :)
>>>> Well, I'll fix it but let me please not send an update...
>>>>
>>>> Thanks!
>>>> Anton.
>>>>
>>