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