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

[Alexander Stepanov]

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