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

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