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

[Alexander Stepanov]

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