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

[Alexander Scherbatiy]

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