Hi Jim!
On 08.02.2014 4:56, Jim Graham wrote:
Hi Anton,
In CPlatformLWWindow.java, why does it have to search for the right device when it was created
with/from a Window object that should already know the right device?
As I wrote before, JLF doesn't have any platform window behind (it's a trully lightweight frame).
That's why we can't simply get an associated device and need some heuristic...
SG2D, line 2114 - I think TRANSFORM_SCALE allows negative scale factors so I think you need a
little more protection from the transform call reversing the rectangle.
Ok, I'll elaborate on it.
Otherwise, I didn't spot any other issues...
Glad to hear that :)
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, casting
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 image 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.
Thanks,
Anton.
...jim
