[OpenJDK 2D-Dev] <AWT Dev> [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

[Jim Graham]

Hi Sergey,

On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
> On 07.11.2013 4:09, Jim Graham wrote:
>> On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
>> That method "returns a scaled version of *this* image".  It
>> specifically refers to recombining the pixels of the image you would
>> normally get into a new image that, by default, renders at the
>> requested size.
>>
>> The method has parameters to control the pixel replication/elimination
>> *algorithm*.
> Custom hint can be renamed to the BEST_EVER_QUALITY_AS_IMAGE_CANhint and
> write in doc that it is nop by default..

No hint can be a nop because the returned image *MUST* render at the 
requested size when passed to drawImage(img, x, y).

All of the hints refer to pixel resampling algorithms, there is no 
history of the hints or that method ever doing anything but pixel 
resampling.  Any ambiguity was left in order to support other pixel 
resampling algorithms in the future and for no other reason.

>> drawImage() should *NOT* be using this method on its own, and the
>> method should not be involved in choosing alternate designs.  It is
>> for manually resampling an image into a new permanent image.
> Why not? We can document that. It is something related to
> |RenderingHints.KEY_INTERPOLATION| which was added as an alternate of
> image hints. But this new hints do not provide possibility to customize
> scaling by the user.

Because it never has.  Because it's operation is specified to be 
asynchronous and so drawImage cannot depend on being able to produce a 
result if it uses that method.  Because it was created to solve a 
different purpose that has nothing to do with on-the-fly source image 
replacement.  Because developers have been free to create their own 
implementations that could do any number of things that would be 
inappropriate inside a drawImage call.  Because you've already 
discovered that, in fact, the default implementation was never anything 
that should ever be done inside a drawImage and you think that providing 
a workaround for that single issue is the answer rather than the fact 
that it should have been a huge wake up call that you barked up the 
wrong tree.

>> Fact: getScaledInstance() *MUST ALWAYS* return an image that is the
>> requested WxH.  It has no other option.  you can't override that *API
>> REQUIREMENT* in the documentation of a hint.  Read the documentation
>> for it: "A new Image object is returned which will render the image at
>> the specified width and height by default."
> Yes, I see. The image should be "new" and it does not say it should be
> the same object. And content of this "new" image depends from the hint
> which was passed to the method.

And, the image must be the indicated WxH - not a different WxH that 
might be somehow compatible with a request to draw at the requested WxH, 
but getWidth() and getHeight() *MUST* return the indicated parameters 
and if you render it with no w,h specified in the drawImage() call then 
it *MUST* draw at the indicated dimensions.

>> You are not understanding that it is a new scaled version of *THIS*
>> image.  The pixels from the original image must be used. This is about
>> pixel replication algorithms, not about redesigning a representation.
> The user know what pixels contains in its image, and he know how to
> scale its better.

But, the spec of the method is specifically geared towards pixel 
resampling, not pixel re-authoring.

				...jim