<AWT Dev> Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

[Alexander Stepanov]

Thank you!

On 2/5/2016 7:58 PM, Alexander Scherbatiy wrote:
>
>  The fix looks good to me.
>
> On 05/02/16 15:59, Alexander Stepanov wrote:
>> Hello Alexandr,
>>
>> Thank you for the notes; yes, these lines are unnecessary. Please see 
>> the updated patch:
>> http://cr.openjdk.java.net/~avstepan/8142861/webrev.04/
>>
>> It should be also mentioned that for now the test is still failing 
>> because of JDK-8143062. Should it be added to any exclude list?
>
>   It is mentioned in the test @bug list. It should be enough because 
> it means that the test should pass when the bug 8143062 is fixed.
>
>   Thanks,
>   Alexandr.
>
>>
>> Thanks,
>> Alexander
>>
>>
>> On 2/5/2016 1:51 PM, Alexander Scherbatiy wrote:
>>>
>>>
>>>  There are just small comments about lines:
>>>  119             Graphics2D g = (Graphics2D) gr;
>>>  120             if (g != null) { g.drawImage(IMG, 0, 0, this); }
>>>
>>>   Is it necessary to cast the Graphics to Graphics2D because 
>>> Graphics also has drawImage(...) method?
>>>   Is it necessary to check the graphics to null? It looks like 
>>> passed null graphics should be considered as a bug.
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>>
>>> On 20/01/16 20:32, Alexander Stepanov wrote:
>>>> Sorry, just a reminder...
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 1/14/2016 6:00 PM, Alexander Stepanov wrote:
>>>>> Hello Sergey,
>>>>>
>>>>> > Note that MultiRes image can be created at runtime
>>>>> Indeed, this case should be used for testing, as we have different 
>>>>> naming conventions for OS X and Windows, so the write-read logic 
>>>>> is thrown away (as we have such tests already), and now the 
>>>>> multiresolution image is created at runtime.
>>>>>
>>>>> Please see the updated webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8142861/webrev.03/
>>>>>
>>>>> Regards,
>>>>> Alexander
>>>>>
>>>>> On 11/16/2015 4:23 PM, Alexander Stepanov wrote:
>>>>>> P.S.: The behavior with Mac OS X mission control should also be 
>>>>>> checked which is definitely a manual job (it seems to be strange 
>>>>>> sometimes; not sure if buggy). So the test instructions should be 
>>>>>> appended a bit...
>>>>>>
>>>>>> On 11/16/2015 3:24 PM, Alexander Stepanov wrote:
>>>>>>> Hello Sergey,
>>>>>>>
>>>>>>> Thank you for the notes.
>>>>>>>
>>>>>>> > Do you have some thoughts why this test cannot be converted to 
>>>>>>> auto test?
>>>>>>>
>>>>>>> The following parts of the test scenario:
>>>>>>>
>>>>>>> - "Please try to drag both parent and child, do it fast several 
>>>>>>> times and check if no artifacts occur." (not very valuable part 
>>>>>>> of the test, but I've seen these artifacts (only once) after 
>>>>>>> fast and long dragging from one display to another, so probably 
>>>>>>> it is better to save it, just in case).
>>>>>>> - "For Mac OS X please check also the behavior for translucent 
>>>>>>> windows appearing on the 2nd (non-active) display"
>>>>>>>
>>>>>>> are hardly automated; especially for Mac OS X because the 
>>>>>>> translucent window on the 2nd "inactive" display sometimes 
>>>>>>> occurs but sometimes not, and I doubt if it could be predicted 
>>>>>>> exactly where and when it should occur when dragging and when 
>>>>>>> stopping dragging (and even change color; - e.g. we can see 
>>>>>>> part  of the "1x" image on "2x" display, if its other part is 
>>>>>>> still on the "1x" display together with cursor).  Please note 
>>>>>>> also that the drag behavior for Mac OS X differs, from e.g., 
>>>>>>> Ubuntu Linux: while dragging the parent dialog we also drag its 
>>>>>>> child (whereas for Ubuntu this is not the case).
>>>>>>>
>>>>>>> Moreover, the test requires not very trivial hardware 
>>>>>>> configuration (HiDPI + non-HiDPI displays, ) which, probably, 
>>>>>>> occurs rarely.
>>>>>>>
>>>>>>> So I believe that the manual test has more chances to be run 
>>>>>>> than automated (and is less prone to false negative); and 
>>>>>>> attempts to automate it will bring more headache than gain.
>>>>>>>
>>>>>>> > Note that MultiRes image can be created at runtime, it will be 
>>>>>>> good to cover this also.
>>>>>>> Will look at this, thanks.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexander
>>>>>>>
>>>>>>> P.S.: probably some simpler test cases could be automated: e.g., 
>>>>>>> switching display resolution and checking correctness of the 
>>>>>>> multires. image displayed, but I'd like to make that separately.
>>>>>>>
>>>>>>> On 11/16/2015 11:35 AM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Alexander.
>>>>>>>>  - Note that MultiRes image can be created at runtime, it will 
>>>>>>>> be good to cover this also.
>>>>>>>> - Do you have some thoughts why this test cannot be converted 
>>>>>>>> to auto test? Probably some api can be added to jdk to simplify 
>>>>>>>> creation of such tests? like already added 
>>>>>>>> "-Dsun.java2d.uiScale"(JDK-8073320).
>>>>>>>>
>>>>>>>> On 13.11.15 14:34, Alexander Stepanov wrote:
>>>>>>>>> webrev updated:
>>>>>>>>> http://cr.openjdk.java.net/~anazarov/8142861/webrev.02/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alexander
>>>>>>>>>
>>>>>>>>> On 11/12/2015 7:51 PM, Alexander Stepanov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you please review the following fix
>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/8142861-3/webrev.00/
>>>>>>>>>> for
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8142861
>>>>>>>>>>
>>>>>>>>>> Just a single manual test added.
>>>>>>>>>> (sorry, I'll remove these unnecessary 'static' modifiers for
>>>>>>>>>> 'parentName', 'childName')
>>>>>>>>>>
>>>>>>>>>> Checked on Mac OS X 10.10 (2-display configuration + Quartz) 
>>>>>>>>>> with JDK9
>>>>>>>>>> b91
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexander
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>