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