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?
On 11.02.2014 23:45, Jim Graham wrote:
Hi Anton,
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...
Thanks for the clarification. (Please, see below.)
...jim
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).
So, HiDPI BI won't be backward compatible (unlike VolatileImage's) in terms of
behavior?
Thanks,
Anton.
