Hello Alexander,
Why don't use the reader method analogue for writer? Then the test could
use the public API which is preferable.
Just a cosmetic note. Lines should be wrapped at 80 position.
--Semyon
On 12/29/2015 3:44 PM, Alexander Stepanov wrote:
Hello Brian,
Thank you for the notes,
you call super.paintComponent(g); twice in lines 956 and 964. Is it
expected behavior?
--Semyon
On 6/1/2016 7:58 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8158408
Webrev: http://cr.openjdk.java.net/~prr/8158408/
At 125% scaling on JDK 9 Font2DTest looks horrid
Looks good to me.
--Semyon
On 6/1/2016 9:44 PM, Phil Race wrote:
On 06/01/2016 11:05 AM, Semyon Sadetsky wrote:
you call super.paintComponent(g); twice in lines 956 and 964. Is it
expected behavior?
Yes, if "CannotDrawException" is caught we want to repaint using super
else, we
Hello,
Please review the fix for jdk9.
bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/
The root cause is incorrect coordinate rounding in D3D renderer. To fix
the issue one of fudge factors was adjusted.
Another issue
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel image but the scaled one. So Mac plat
On 1/15/2016 6:46 PM, Sergey Bylokhov wrote:
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the sc
/~avstepan/8145776/webrev.02/
Thanks,
Alexander
On 1/11/2016 11:59 AM, Semyon Sadetsky wrote:
Hello Alexander,
Why don't use the reader method analogue for writer? Then the test
could use the public API which is preferable.
Just a cosmetic note. Lines should be wrapped at 80 position.
--Semyon
phil.
On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:
Hello,
Please review the fix for jdk9.
bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev: http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/
The root cause is incorrect coordinate rounding in D3D renderer. To
fix the issue
On 1/16/2016 12:10 AM, Sergey Bylokhov wrote:
On 15/01/16 19:40, Semyon Sadetsky wrote:
On 1/15/2016 6:46 PM, Sergey Bylokhov wrote:
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I
On 2/7/2016 11:37 PM, Sergey Bylokhov wrote:
On 01.02.16 12:23, Semyon Sadetsky wrote:
On 1/21/2016 5:04 PM, Sergey Bylokhov wrote:
On 19/01/16 14:30, Semyon Sadetsky wrote:
We are getting error because of incorrect fudge factor added to the
"to"
line coordinates (for
Looks good to me.
--Semyon
On 1/19/2016 7:17 PM, Alexander Stepanov wrote:
Hello Sergey,
please find the updated webrev:
http://cr.openjdk.java.net/~avstepan/8146881/webrev.01/index.html
Regards,
Alexander
On 1/18/2016 5:12 PM, Sergey Bylokhov wrote:
On 15/01/16 15:27, Alexander Stepanov
Bylokhov wrote:
On 01.02.16 12:23, Semyon Sadetsky wrote:
On 1/21/2016 5:04 PM, Sergey Bylokhov wrote:
On 19/01/16 14:30, Semyon Sadetsky wrote:
We are getting error because of incorrect fudge factor added to the
"to"
line coordinates (for line from - to).
See the updated version
and
it passed on my ATI card.
-phil.
On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:
On 15.01.16 9:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
pixel to
pixel i
approved.
--Semyon
On 4/5/2016 9:45 PM, Phil Race wrote:
I have an approved CCC sitting waiting for a 2nd reviewer on the code
change
-phil.
On 03/25/2016 11:31 AM, Sergey Bylokhov wrote:
Looks fine.
On 25.03.16 20:56, Phil Race wrote:
After a hallway conversation I have decided to
On 3/25/2016 1:43 AM, Andrej Golovnin wrote:
Hi Phil,
That is true .. although I think I have previously been convinced that IAE
is generally the better choice for such a case, I found only deriveFont
that throws IAE for null in this file.
So the question is whether to be consistent or to
Looks good.
--Semyon
On 3/31/2016 6:52 PM, Alexander Stepanov wrote:
Please see
http://cr.openjdk.java.net/~avstepan/8149028/webrev.02/
(one more test covering TIFFImageReadParam was added).
Thanks,
Alexander
On 3/29/2016 8:21 PM, Alexander Stepanov wrote:
Please see the updated webrev:
On 7/7/2016 7:48 PM, Ajit Ghaisas wrote:
Thanks Phil for the review.
Please find my answers below.
Semyon, can you please comment on Phil's question below?
I agree with this change. The check is not needed.
--Semyon
Regards,
Ajit
-Original Message-
From: Phil Race
Sent: Wednesday,
problems and
it passed on my ATI card.
-phil.
On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:
On 15.01.16 9:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact
p
On 9/9/2016 4:08 PM, Vadim Pakhnushev wrote:
On 09.09.2016 15:58, Semyon Sadetsky wrote:
On 09.09.2016 14:45, Vadim Pakhnushev wrote:
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated
On 09.09.2016 14:45, Vadim Pakhnushev wrote:
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated to this fix. Could you upgrade to the latest driver
from
I have reworked fix to not affect ATI and NVidia.
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/
--Semyon
On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:
On 08.09.2016 22:57, Philip Race wrote:
Can you provide something like a rationale for why these particular
values might work
{ 0x1002, 0x714A, D_VERSION(6,14,10,6706), OS_WINXP },
{ 0x1002, 0x714A, D_VERSION(7,14,10,0567), OS_VISTA },
---
-phil.
On 9/8/16, 4:06 PM, Semyon Sadetsky wrote:
I have reworked fix to not affect ATI and NVidia.
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/
--Semyon
On 9
On 09.09.2016 13:43, Vadim Pakhnushev wrote:
On 09.09.2016 13:12, Semyon Sadetsky wrote:
On 09.09.2016 12:56, Vadim Pakhnushev wrote:
Semyon,
I can reproduce JDK-803944 on my machine with your fix.
More importantly, the RenderRectTest is passed for me on Windows 7
on ATI and Intel cards
can easily show this fix resolves all of these ..
-phil.
On 9/8/16, 5:12 PM, Semyon Sadetsky wrote:
I have 2 laptops Intel i5, i7. Both working with d3d normally. Some
visual defects will be corrected after this fix.
And I didn't get why d3d is disabled for all Intel without
possibility
er.
Vadim
On 12.09.2016 21:11, Semyon Sadetsky wrote:
http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.01/
AccelDeviceEventNotifier is removed.
--Semyon
On 9/12/2016 6:56 PM, Semyon Sadetsky wrote:
Okay. I will remove AccelDeviceEventNotifier and all related code.
--Semyon
On 9/12/2016 6:43
http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.01/
AccelDeviceEventNotifier is removed.
--Semyon
On 9/12/2016 6:56 PM, Semyon Sadetsky wrote:
Okay. I will remove AccelDeviceEventNotifier and all related code.
--Semyon
On 9/12/2016 6:43 PM, Vadim Pakhnushev wrote:
Hi Semyon
think you can easily show this fix resolves all of these ..
-phil.
On 9/8/16, 5:12 PM, Semyon Sadetsky wrote:
I have 2 laptops Intel i5, i7. Both working with d3d normally. Some
visual defects will be corrected after this fix.
And I didn't get why d3d is disabled for all Intel without
possibility
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8155753
webrev: http://cr.openjdk.java.net/~ssadetsky/8155753/webrev.00/
The issue take place on Windows platform if Direct3d is on. The
notification routine about the monitor removal tries to get screen
number
.
Not sure how the rest of the code handles monitor removal, seems to me
that there are no usages of this notifications anywhere, so maybe we
don't need this code at all?
Thanks,
Vadim
On 12.09.2016 17:24, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https
Race wrote:
No .. that would be an incompatible change that might surprise a lot
of people.
-phil.
On 9/9/16, 12:31 AM, Semyon Sadetsky wrote:
I cannot reproduce JDK-803944. It is about very specific hardware
configuration with two different video cards.
I didn't find any evaluation/jus
yes, this is a potential issue. But actually cases MID,FOCUS,BLACK,WHITE
are never used.
But the fix is wrong. It should be
color.alpha = 1; --Semyon
On 01.12.2016 08:05, Prasanta Sadhukhan wrote:
Also, in gtk3_interface.c, there is this change for color.alpha
2219 color.alpha = 0; in
On 04/30/2017 07:55 PM, Sergey Bylokhov wrote:
Hi, Semyon.
Should the GLXVSyncOffScreenSurfaceData/WGLVSyncOffScreenSurfaceData be updated
as well? Seems it were also overlooked.
I thinks that instead of «noreg-sqe» label it would be better to add the new
bugid to the failed test.
The
Hello,
Please review fix for JDK10 (in Swing and Java2D):
bug: https://bugs.openjdk.java.net/browse/JDK-8187367
webrev: http://cr.openjdk.java.net/~ssadetsky/8187367/webrev.00/
Swing apps may have artifacts on HiDPI screens with fractional scales.
There are several issues which may cause
artifacts at
fractional scales before the fix.
On 9/18/17 09:36, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK10 (in Swing and Java2D):
bug: https://bugs.openjdk.java.net/browse/JDK-8187367
webrev: http://cr.openjdk.java.net/~ssadetsky/8187367/webrev.00/
Swing apps may have
+1
--Semyon
On 10/09/2017 11:09 AM, Phil Race wrote:
A test fix .. to catch OOME from StringBuilder.append() as well
as the API that is under test.
I don't think there's anything specific to G1 here, it could
have happened with other collectors.
bug :
oc comments unnecessarily, and
not changing them in a way to provoke this bad behavior.
-- Jon
On 11/22/2017 12:10 PM, Semyon Sadetsky wrote:
Hi Jon,
This is not only about HTML5 spec, I also hardly can find resources
that follow your "
You are correct that there is no bug here. But a bu
and the AWT team want to proceed
with those changes, I'm done.
-- Jon
On 11/22/17 7:46 PM, Semyon Sadetsky wrote:
Jon,
This is because you have fixed page header. For me it works equally
in all browsers. I see no discrepancy between Chrome and Firefox on
my Linux platform. I believe
edback, which remains to not introduce
changes which may cause visual issues. If you and the AWT team want
to proceed with those changes, I'm done.
-- Jon
On 11/22/17 7:46 PM, Semyon Sadetsky wrote:
Jon,
This is because you have fixed page header. For me it works equally
in all br
ferently, and I cannot say that
what you are suggesting is against the spec; I can just say that we
can seen cases where such changes leads to bad visual effects.
-- Jon
On 10/25/17 6:31 PM, Semyon Sadetsky wrote:
Hi Jonathan,
On 10/24/2017 03:20 PM, Jonathan Gibbons wrote:
Semyo
difference between
navigating to "
--Semyon
[1] https://www.w3schools.com/html/html_links.asp
[2] http://www.html5-tutorials.org/html-basics/links/
[3] https://www.w3.org/TR/html5/browsers.html#scroll-to-fragid
-- Jon
On 10/23/2017 10:08 PM, Semyon Sadetsky wrote:
Hi Sergey,
I see no
to be updated according to it. In html5 you need only if
you want to see hyperlink and your fix is modifying those tags.
--Semyon
On 23/10/2017 22:08, Semyon Sadetsky wrote:
Hi Sergey,
I see no reason to have an extra empty anchor tag to set a bookmark.
The id attribute works with any element
On 03/08/2018 02:24 PM, Sergey Bylokhov wrote:
On 08/03/2018 14:11, Semyon Sadetsky wrote:
That's doesn't make any sense. The w/o jtreg it is run manually and
it is always known on what is the platform. There may be a need to
run the test on another platform but this redundant check makes
On 03/08/2018 12:47 PM, Sergey Bylokhov wrote:
On 08/03/2018 12:38, Semyon Sadetsky wrote:
This check was added for the case when the test will be run in
standalone w/o jtreg
That's doesn't make any sense. The w/o jtreg it is run manually and
it is always known on what is the platform
On 03/08/2018 12:03 PM, Sergey Bylokhov wrote:
On 08/03/2018 08:30, Semyon Sadetsky wrote:
Please remove redundant platform detection code since this is done in
the jtreg header now.
This check was added for the case when the test will be run in
standalone w/o jtreg
That's doesn't make any
Hi Sergey,
Please remove redundant platform detection code since this is done in
the jtreg header now.
--Semyon
On 03/07/2018 07:32 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk11.
Bug: https://bugs.openjdk.java.net/browse/JDK-8198406
Webrev can be found at:
On 6/6/19 9:12 AM, Phil Race wrote:
On 6/6/19 9:11 AM, semyon.sadet...@oracle.com wrote:
On 6/5/19 6:43 PM, Philip Race wrote:
On 6/5/19, 4:18 PM, Semyon Sadetsky wrote:
On 6/5/19 2:11 PM, Phil Race wrote:
It *can* make a difference and in fact we have a regression test
that now
I don't know how timely it is to cleanup this code. Anyway, you've
removed global awtJNI_GetFontData() function but left its external
declaration in open/src/java.desktop/unix/native/common/awt/awt_p.h:
On 6/5/19 2:11 PM, Phil Race wrote:
It *can* make a difference and in fact we have a regression test
that now passes with this fix which tests different rendering modes.
Which test is it? Why you didn't mark it with the bug id?
However that is not a direct test for this potential difference.
Can you clarify does the change affects font metrics?
I see that it is a sub-pixel difference for each single glyph but if a
long line of text can accumulate a notable difference the reg test can
be provided.
--Semyon
On 6/5/19 11:43 AM, Phil Race wrote:
bug:
On 6/5/19 6:43 PM, Philip Race wrote:
On 6/5/19, 4:18 PM, Semyon Sadetsky wrote:
On 6/5/19 2:11 PM, Phil Race wrote:
It *can* make a difference and in fact we have a regression test
that now passes with this fix which tests different rendering modes.
Which test is it? Why you didn't mark
50 matches
Mail list logo
