Hi Sergey,
I have two questions:
1.
As I read about NSOpenGLPFAAllowOfflineRenderers attribute here
https://developer.apple.com/library/mac/technotes/tn2229/_index.html
To support Mac OS X 10.4 or earlier, you will need to remove this
attribute from your attribute list, as otherwise pixel form
The fix looks good.
Thanks.
Semyon
On 10/20/2015 5:37 PM, Sergey Bylokhov wrote:
On 20.10.15 14:52, Semyon Sadetsky wrote:
1.
As I read about NSOpenGLPFAAllowOfflineRenderers attribute here
https://developer.apple.com/library/mac/technotes/tn2229/_index.html
To support Mac OS X 10.4 or
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, pl
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 men
MD/ATI card.
-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
f
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. S
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 t
a.net/~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.
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
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 wr
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 of the fix in which test should work on
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 line
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
s 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
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 sta
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:
http
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 change
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 sin
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
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,
build
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 ret
isted in 8039444.
--Semyon
IIRC Semyon will need to change the code to bypass the check
for Intel hardware. There is no env. variable or system property to do
this.
-phil.
On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:
On 05.09.16 13:36, Semyon Sadetsky wrote:
At last I could get NVidia ma
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
b ids)
{ 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/
--Sem
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
don't 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 witho
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
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 https://downloadcenter.intel.com/search?keywo
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 to this
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:
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
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
On 9/12/2016 10:36 PM, Vadim Pakhnushev wrote:
Looks good to me (have you submitted JPRT job just in case?)
Is JPRT really necessary? The native part is only changed for Windows on
which the build is deterministic.
--Semyon
Vadim
On 12/09/16 22:31, Semyon Sadetsky wrote:
I missed this
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 evaluatio
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 gtk3
Hello,
Please review the fix for jdk9.
bug: https://bugs.openjdk.java.net/browse/JDK-8178984
webrev: http://cr.openjdk.java.net/~ssadetsky/8178984/webrev.00/
Angle brackets around "true" are removed.
--Semyon
Hello,
Please review the fix for jdk9.
bug:https://bugs.openjdk.java.net/browse/JDK-8159902
webrev: http://cr.openjdk.java.net/~ssadetsky/8159902/webrev.00/
Probably, HiDPI support for Linux OGL was forgoten.
Fix tries to add it now...
--Semyon
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 GLXVSync
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 var
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 : https://bugs.openjdk.java.net/browse/JDK
Hi Sergey,
I see no reason to have an extra empty anchor tag to set a bookmark. The
id attribute works with any element.
For example:
Definitions
should be
Definitions
--Semyon
On 10/23/2017 02:42 PM, Sergey Bylokhov wrote:
Hello,
Please review the fix for.
8182410: missing
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
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 re
Hello,
Please review fix for JDK10:
bug: https://bugs.openjdk.java.net/browse/JDK-8190228
webrev: http://cr.openjdk.java.net/~ssadetsky/8190228/webrev.00/
The fix cleanups Java2D, Swing and AWT code to remove the redundant code
like:
SomeClass *extends Object*
private *final* ...someMethod
t differently, 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
rwise changing the doc 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
sues. 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 browsers. I see no discrepancy between Chrome and Firefox on
my Linux pla
review feedback, 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 equall
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:
http://cr.op
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'
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 platf
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 chec
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: https://bugs.openjdk.java.net/b
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.
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
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:
http://hg.openjdk.java.net/jdk/client/file/f680bedc0dcb/src/java.desktop/unix/native/common/
59 matches
Mail list logo