On 5/13/14 9:29 PM, Anthony Petrov wrote:
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:
Please do not push it, i'll try to decrease the changes. Will send an
update tomorrow.
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.
--
Best regards, Sergey.
