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

Alexander Stepanov alexander.v.stepanov at oracle.com
Fri Feb 5 11:59:44 UTC 2016


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?

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



More information about the awt-dev mailing list