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
