PM, Sergey Bylokhov wrote:
On 30.11.16 2:11, Jim Graham wrote:
- Region.getScaledRegion() - this method should be deleted. I think it
is only used in SG2D.constrain() which needs to be rewritten as you
cannot scale a region and expect any amount of accuracy, but we live
with it for now until
is removed
- Region.clipRound() is used for pixels coordinates rounding.
Thanks,
Alexandr.
On 11/16/2016 1:52 AM, Jim Graham wrote:
Let me clarify something...
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Let's consider the following use case:
scale = 1.5
A component calls fillRect(1
I've filed JDK-8170514 to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8170514
...jim
On 11/29/16 10:11 PM, Jim Graham wrote:
I took another look at the use of clipScale/clipRound in the SG2D.drawHiDPI
method.
The sub-image parameters are given relative
Have I confused enough people at this point with the subtleties of this code?
:(
I should submit a bug to improve our image pipeline for scaled sub-images...
...jim
On 11/29/16 3:11 PM, Jim Graham wrote:
clipRound() has appropriate logic for matching the results of filling a p
moved from the SunGraphics2D
to the SwingUtilities2 class.
Thanks,
Alexandr.
On 11/18/2016 11:23 PM, Jim Graham wrote:
Hi ALexandr,
This looks great.
BTW, when I suggested moving the FPscale test into SG2D I was
suggesting that to avoid having to copy the transform out of it via
ge
to the
SwingUtilities2 class.
Thanks,
Alexandr.
On 11/18/2016 11:23 PM, Jim Graham wrote:
Hi ALexandr,
This looks great.
BTW, when I suggested moving the FPscale test into SG2D I was suggesting that
to avoid having to copy the transform
out of it via getTransform(), but you've found a different
adjustment is removed
- Region.clipRound() is used for pixels coordinates rounding.
Thanks,
Alexandr.
On 11/16/2016 1:52 AM, Jim Graham wrote:
Let me clarify something...
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Let's consider the following use case:
scale = 1.5
A component calls
Let me clarify something...
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Let's consider the following use case:
scale = 1.5
A component calls fillRect(1, 1, 1, 1).
This is (1.5, 1.5, 3.0, 3.0) in the device space
which fills (1, 1, 3, 3) and covers 2x2 pixels
Agreed.
Now the
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Were you seeing that happen? Because that would be a rendering bug in
fillRect...
Let's consider the following use case:
scale = 1.5
A component calls fillRect(1, 1, 1, 1).
This is (1.5, 1.5, 3.0, 3.0) in the device space
which fills
I want to clarify the following issue...
On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote:
Using floating point scale leads that drawing the same thing from
different coordinates gives different results. For example filling a
rectangle with size (1, 1) from location (0, 0) and UI scale 1.5
Hi Alexandr,
On 11/14/2016 7:51 AM, Alexandr Scherbatiy wrote:
The current fix tries to adjust the component translation to a value
which allows to draw a component in the same way when floating point
scale is used.
The scale is converted to the irreducible fraction n / m where m is
the
Is SunGraphics2D accessible from Swing? If so, then I'd recommend
putting the isFPScale() method right on that class so we don't have to
clone the transform by calling g.getTransform(). Also note that
g.getTransform() does more than clone the transform as it has to factor
out the constrainXY
Thank you in advance.
With Regards,
Avik Niyogi
On 28-Oct-2016, at 1:18 am, Jim Graham <james.gra...@oracle.com
<mailto:james.gra...@oracle.com>> wrote:
Hi Avik,
My suggestion about adding a word "the" was not taken and a couple of other
changes were made to
gi/8138771/webrev.04/*
Thank you in advance.
With Regards,
Avik Niyogi
On 27-Oct-2016, at 2:33 am, Jim Graham <james.gra...@oracle.com
<mailto:james.gra...@oracle.com>> wrote:
The "@return" tags should not start with "returns" in the text.
Also, in th
The "@return" tags should not start with "returns" in the text.
Also, in the @return for getProperty(), insert a word "the" as "the property of the
base image"...
...jim
On 10/26/16 12:36 AM, Avik Niyogi wrote:
Hi All,
Please review the proposed specification for
Hi Alexandr,
Is the fully scaling code noticeably slower than the regular code? Is there a reason to test and only use it
conditionally? It shouldn't be a lot of overhead considering everything else that goes on during a repaint. Some of
the set/unset of attributes could also be optimized
:10, Jim Graham wrote:
Hi Alexandr,
Should something be done to transfer the array of sizes to the new
instance if the source is an MRCI? Perhaps a special case for MRCI as
well that calls mrciInstance.map(mapper) instead of constructing a
brand new object from scratch?
...jim
On 08
/2016 01:32 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.03
MultiResolutionToolkitImage handing is added to the
MultiResolutionCachedImage.map() method.
Thanks,
Alexandr.
On 11/08/16 01:46, Jim Graham wrote:
Ah, yes, only
non-MRCI...
...jim
On 8/10/16 5:35 AM, Alexander Scherbatiy wrote:
On 09/08/16 03:49, Jim Graham wrote:
Does MultiResolutionCachedImage.map() work if the Image hasn't been loaded yet
(where getWidth/Height(Observer) can
return -1)? Can it ever be called in a case like that?
Could we rely o
Another reason to avoid new API is that we don't have to involve the CCC to get this
"bug fix" in...
...jim
On 5/13/16 3:50 PM, Jim Graham wrote:
That looks very tight. The only issue I'd have is that it would be better if
this could be done with non-
-resolution image to another:
Image image = // original image
Image filteredImage = MultiResolutionImage.map(image, (img) -> /* return
filtered image */);
Thanks,
Alexandr.
On 21/03/16 22:31, Jim Graham wrote:
We could do that for our own filters, but any random cus
We could do that for our own filters, but any random custom filter could
run into the same issue, so it might not make sense to upgrade the
existing filter mechanism to always attempt to do MR filtering. We
could either create a parallel set of MR-aware filter mechanisms (such
as the
Is this tied in with ImageFilter/FilteredImageSource?
It looks like since FIS takes only a Producer, it has lost the handle to
the image to get a source for a particular resolution. What happens if
we introduce MultiResolution[Image]Producer? It would provide a single
method that would
The new code in SwingUtilities2 looks good to me, so I'll approve that
file. I'll leave the code in the rest of the files to Petr...
...jim
On 4/4/14 6:37 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
The problem became visible, when we draw a
On 12/11/13 2:40 AM, Anton V. Tarasov wrote:
On 10.12.2013 23:57, Anthony Petrov wrote:
I think that the image shouldn't be aware of any scale.
The scale field put into the BufferedImage class means that an image
instance should (or shouldn't) be treated as a HiDPI image by the
25 matches
Mail list logo
