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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon May 14 21:58:35 UTC 2018


On 13/05/2018 23:55, shashidhara.veerabhadraiah at oracle.com wrote:
> 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.

Then it is unclear why the colors are different for different pixels, 
since the test draws opaque red/blue rectangles.

> 
> 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()
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.


More information about the awt-dev mailing list