Hi, Jim, Phil.
> That sounds useful, but is your example code complete? Don't you need
> to declare the "image" variable with the
> appropriate generic type?
I guess its s too late to change it right now?
Now I thinking of possibility to change the Robot API to simplify its usage in
the tests.
That sounds useful, but is your example code complete? Don't you need to declare the "image" variable with the
appropriate generic type?
Also, do we get a lot of compiler warnings if you want to ignore the generics in other code? What's the pain point if
you don't care what the types of the i
This would be a reasonable thing to try to fix before 9 GA I think.
Can't affect many tests since the code is new ..
-phil.
On 3/29/17, 1:22 PM, Sergey Bylokhov wrote:
Hi, Jim, Phil.
I have started to use MRI and a new Robot in some of the tests and
wonder why the MultiResolutionImage does no
Hi, Jim, Phil.
I have started to use MRI and a new Robot in some of the tests and wonder why
the MultiResolutionImage does not use generics for getResolutionVariants()?
So for example if we have an API like:
http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScre
That looks good. I'm not sure what the standard practice is these days
for using @code vs @link in comments. I think we used to have some sort
of "first reference is @link, subsequent are @code" convention, but that
may have changed, especially if you @see them as well and the 2
paragraphs ar
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.13
- The javadoc for MultiResolutionImage interface is updated.
On 8/26/2015 1:45 AM, Phil Race wrote:
On 08/25/2015 02:26 PM, Jim Graham wrote:
Is MRI intended to be implemented only by classes that exten
> On Aug 25, 2015, at 23:26, Jim Graham wrote:
>
> Should we list the naming conventions that we support (mainly just "@2x"?),
> or should that be listed in the documentation of the various getImage() and
> createImage() methods?
As mentioned back in April
(http://mail.openjdk.java.net/piper
On 08/25/2015 02:26 PM, Jim Graham wrote:
Is MRI intended to be implemented only by classes that extend
java.awt.Image? I think that's the only place we look for it. If so,
then we should state that. Perhaps:
-
This interface is designed to be an optional additional API supported
b
Is MRI intended to be implemented only by classes that extend
java.awt.Image? I think that's the only place we look for it. If so,
then we should state that. Perhaps:
-
This interface is designed to be an optional additional API supported by
some implementations of {java.awt.Image}
Looks fine.
On 19.08.15 14:51, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.12
Javadoc description is updated in some places and parameters
checking is added:
- @throws IllegalArgumentException tag is added
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.12
Javadoc description is updated in some places and parameters checking
is added:
- @throws IllegalArgumentException tag is added for
MultiResolutionImage.getResolutionVariant(destImageWidt
Hi Alexandr,
All of the new changes look good. Only one minor issue in a comment in
the test:
MRRHT.java, line 85: should be "is not based on rendered size" or
something to that effect
(No need for a new webrev to fix that print statement.)
I have a separate question out to Phil on wheth
Hello Jim,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.10/
- the suggested comments are updated
- the MultiResolutionRenderingHintsTest is updated to use custom
GraphicsConfiguration and SurfaceData
On 7/23/2015 8:25 PM, Jim Graham wrote:
Hi A
Hi Alexandr,
On 7/21/15 7:41 AM, Alexander Scherbatiy wrote:
Hello Jim,
Thank your for the review.
Could you review the updated fix there the suggested comments are
updated:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/
Minor comments embedded below.
On 7/14/2015 2:36
Hello Jim,
Thank your for the review.
Could you review the updated fix there the suggested comments are updated:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.09/
On 7/14/2015 2:36 AM, Jim Graham wrote:
Hi Alexandr,
Sorry that this fell into the cracks. Here are some fairly mi
It seems you are making an assumption that the code that creates the image is
somehow initiated from a paint method so that the display scale factor can be
obtained from the graphics context and used to determine the required image
resolution. That is not the scenario I am concerned about.
I am
I am commenting on your suggestion that I can determine which display the image
will displayed on.
> On Jul 15, 2015, at 7:42 AM, Alexander Scherbatiy
> wrote:
>
> On 7/15/2015 5:09 PM, Alan Snyder wrote:
>>
>> It seems you are making an assumption that the code that creates the image
>> i
On 7/15/2015 5:09 PM, Alan Snyder wrote:
It seems you are making an assumption that the code that creates the
image is somehow initiated from a paint method so that the display
scale factor can be obtained from the graphics context and used to
determine the required image resolution. That is
On 7/14/2015 3:18 AM, Alan Snyder wrote:
I have a concern about how custom multiresolution images are supported based on
a problem I ran into using the JDK 8 classes, which are similar.
The problem is that the selection of a variant image happens during painting.
That is a very bad time to act
I have a concern about how custom multiresolution images are supported based on
a problem I ran into using the JDK 8 classes, which are similar.
The problem is that the selection of a variant image happens during painting.
That is a very bad time to actually try to render an image, if one is in
Hi Alexandr,
Sorry that this fell into the cracks. Here are some fairly minor updates:
AbstractMRI - getGraphics() should include "getGraphics() not supported
on Multi-Resolution Images" as the exception description text.
AbstractMRI - getBaseImage() should have doc comments:
/**
* Return t
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/
- SunGraphics2D is updated to calculate the resolution variant size
according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution rendering hint
- MultiResolutionRenderingHints test is added
This is an interesting suggestion that would let us keep the
implementation of the various hints centralized and simplify the
interface to the part of the mechanism that is most tied in to the
implementation specifics of the database of media variants - which is
housed in the MRI-implementing o
> On Apr 1, 2015, at 15:46, Alexander Scherbatiy
> wrote:
>
> On 3/27/2015 12:48 AM, Jim Graham wrote:
>> Hi Alexander,
>
> http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
> I have updated the fix according to the comments except RenderingHints.
Alexandr,
I've noticed that the Mul
On 3/27/2015 12:48 AM, Jim Graham wrote:
Hi Alexander,
http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
I have updated the fix according to the comments except RenderingHints.
RenderingHints are supposed to be set on Graphics2D and they have
keys/values which are not relevant t
Hello, Jim.
27.03.15 0:48, Jim Graham wrote:
RenderingHints.java:
Where do we process this hint? Don't we need to pass it to the
getVariant() method?
I don't understand the hint values other than the one that always uses
the base image. Default I guess gives us the ability to use the Mac
Hi Alexander,
MRI.java:
Who is the intended audience for the recommendation in the interface to
cache image variants? Are we asking the developers who call the methods
on the interface to cache the answers? That would be unwise because the
list of variants may change over time for some MRIs
> On Mar 13, 2015, at 14:34, Alexander Scherbatiy
> wrote:
>
> Could you review the proposed API based on MultiresolutionImage interface:
>http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
Not that it counts much, but to me the proposed API looks good in that it
provides us with mul
Hello,
Could you review the proposed API based on MultiresolutionImage
interface:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
- return unmodifiable list comment is added to the
getResolutionVariants() method javadoc in MultiresolutionImage interface
- base image size arg
The second solution looks good. I'd make it standard practice (perhaps
even mentioned in the documentation) to return unmodifiable lists from
the getVariants() method. The Collections class provides easy methods
to create these lists, and it sends a clear message to the caller that
the list w
Hi Alexander,
The code that lets someone modify an existing image has an important and
undesirable side effect of making images mutable. Since we cache images
internally, they are treated as immutable so that if two unrelated
parties ask for an image that comes from a specific URL, we can giv
Hi Phil,
I have prepared two versions of the proposed API:
I) Resolution variants are added directly to the Image:
http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
II) MultiResolutionImage interface is used:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
It
32 matches
Mail list logo
