<AWT Dev> [11] JDK-8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java

[shashidhara.veerabhadraiah at oracle.com]

Hi Sergey, Below are some of the samples captured after debugging:

This is with a scale of 2. So 4 sub pixels per location. Here are there 
colors:

Pixel info:java.awt.Rectangle[x=132,y=184,width=2,height=2]
------------------------------------------------------
Pixel colors: --13462275
Pixel colors: --13659139
Pixel colors: --13462275
Pixel colors: --13659139
Pixel info:java.awt.Rectangle[x=136,y=184,width=2,height=2]
------------------------------------------------------
Pixel colors: --14250242
Pixel colors: --14512898
Pixel colors: --14315779
Pixel colors: --14447362
Pixel info:java.awt.Rectangle[x=140,y=184,width=2,height=2]
------------------------------------------------------
Pixel colors: --15104002
Pixel colors: --15301122
Pixel colors: --15038210
Pixel colors: --15300866
Pixel info:java.awt.Rectangle[x=144,y=184,width=2,height=2]
------------------------------------------------------
Pixel colors: --15760641
Pixel colors: --15891969
Pixel colors: --15760641
Pixel colors: --15891969
Pixel info:java.awt.Rectangle[x=148,y=184,width=2,height=2]
------------------------------------------------------
Pixel colors: --16285953
Pixel colors: --16687873
Pixel colors: --16286209
Pixel colors: --16687873

As you can see here, it is possible to have different colors for each 
sub pixel, but the getPixelColor() will invariably choose only the first 
pixel color.

Thanks and regards,

Shashi


On 13/05/18 12:04 PM, Sergey Bylokhov wrote:
> On 12/05/2018 21:47, shashidhara.veerabhadraiah at oracle.com wrote:
>> Hi Sergey, Small correction. If the HiDpi factor is 3, then assuming 
>> uniform scaling on x and y, it will be a 3 * 3 area representing a 
>> single coordinate point. getPixelColor() will always pick the first 
>> point color but the createScreenCapture() would pick the closest one 
>> pixel among the 3 * 3.
>
> But getPixelColor() will return the real pixel which was painted by 
> the test on the screen. If the test will draw blue/red square then 
> getPixelColor() should return blue/red pixel(even if it was the first 
> left/top pixel in the point).
>
>
>>
>> Thanks and regards,
>>
>> Shashi
>>
>>
>> On 12/05/18 9:45 PM, shashidhara.veerabhadraiah at oracle.com wrote:
>>> Hi Sergey, I read that slightly different. The getPixelColor() would 
>>> not be accurate but createScreenCapture() works differently but 
>>> advantageous to us. The reason for that is that if we have a HiDpi 
>>> factor screen of say 3, then actually 3 sub pixels forms each 
>>> particular location. The getPixelColor() would always choose the 
>>> first pixel(0th) whereas createScreenCapture() since it converts to 
>>> low res image using the nearest neighbor, it would choose the color 
>>> of the most nearest point for that particular location.
>>>
>>> We don't need the information of the 3 pixel color info but since 
>>> the limitation of getPixelColor() is that it can return only one 
>>> color and that color should actually be closest to that particular 
>>> location. But instead we always return the first pixel color. On the 
>>> other hand, createScreenCapture() would choose the closest pixel out 
>>> of the 3 pixel color info, which is required in our case.
>>>
>>> This is what I felt out of the 2 ways, please let me know what do 
>>> you think of this.
>>>
>>> Thanks and regards,
>>>
>>> Shashi
>>>
>>>
>>> On 12/05/18 4:38 AM, Sergey Bylokhov wrote:
>>>> Hi, Shashi.
>>>> It means that the updated test will not trust getPixelColor() which 
>>>> returns exact color which is drawn on the screen, but will trust 
>>>> createScreenCapture() which will apply transformation of the actual 
>>>> color. This looks odd.
>>>>
>>>> On 11/05/2018 00:45, shashidhara.veerabhadraiah at oracle.com wrote:
>>>>> 1. In this case we will be using the low resolution variant of the 
>>>>> image that was captured.
>>>>>
>>>>> 2. The low resolution variant was created from the high resolution 
>>>>> image that was actually captured from an high res display. This is 
>>>>> done using the nearest neighbor interpolation which actually 
>>>>> chooses the most nearest point's value and ignores the other 
>>>>> points values completely.
>>>>>
>>>>> This may be a reason to get a different color for the said pixel.
>>>>>
>>>>>
>>>>> By using the getPixelColor():
>>>>>
>>>>> 1. This calls the getRGBPixel().
>>>>>
>>>>> 2. Here we return only the 0th pixel color ignoring the scaling 
>>>>> effect in the case of hidpi display units, where there may be many 
>>>>> sub pixels for the given user space coordinates.
>>>>>
>>>>> This may be the reason for getting failed here.
>>>>>
>>>>>
>>>>> Thanks and regards,
>>>>>
>>>>> Shashi
>>>>>
>>>>>
>>>>> On 11/05/18 2:39 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Shashi.
>>>>>>
>>>>>> On 10/05/2018 08:40, Shashidhara Veerabhadraiah wrote:
>>>>>>> The test was failing because of the color value mismatches, the 
>>>>>>> fix is to get an image of the part of the window for which color 
>>>>>>> needs to be fetched from the image pixel.
>>>>>>
>>>>>> Can you please clarify why r.getPixelColor(x, y) returns 
>>>>>> incorrect color and r.createScreenCapture(bouns{x,y,1,1}) will 
>>>>>> work, since internally both of these methods are use the same 
>>>>>> method CRobot.getRGBPixels()
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>