of the FontMetrics.getWidths() the same as in the
test? I think it does not break the new spec and the test will pass.
On 4/28/20 12:38 pm, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8221305
Webrev: http://cr.openjdk.java.net/~prr/8221305/
Now that we have resolved
JDK-8230672 : Specification
Bug: https://bugs.openjdk.java.net/browse/JDK-8221305
Webrev: http://cr.openjdk.java.net/~prr/8221305/
Now that we have resolved
JDK-8230672 : Specification for java.awt.FontMetrics.getMaxAdvance() is
too prescriptive.
with an approved CSR, the assertion being tested by
I reviewed http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html
and I think you covered all the cases.
I also reviewed the reader and it seems we already check only up to 80
chars there.
I note we assume the same max length of 80 for the language tag for iTxt.
The spec. doesn't specify a
started failing on
jdk11-b05 and started passing from jdk11-b17.
+1
Regards
Prasanta
On 27-Apr-20 5:29 AM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8197797
webrev : http://cr.openjdk.java.net/~prr/8197797/
I can't reproduce this anywhere despite trying hard
Bug: https://bugs.openjdk.java.net/browse/JDK-8197797
webrev : http://cr.openjdk.java.net/~prr/8197797/
I can't reproduce this anywhere despite trying hard.
The closest is I saw 8u221 on mac 10.13.6 show *slight* differences in
alignment but not nearly enough for the test to fail.
More details
Updated webrev : http://cr.openjdk.java.net/~prr/8230672.1/
And CSR for review : https://bugs.openjdk.java.net/browse/JDK-8243566
-phil
On 4/24/20, 3:00 AM, Sergey Bylokhov wrote:
On 4/23/20 10:00 am, Philip Race wrote:
I am not 100% sure what you are getting at, but maybe
"render
On 4/23/20, 9:49 AM, Sergey Bylokhov wrote:
On 4/23/20 9:34 am, Philip Race wrote:
No, I don't see the relationship.
charWidth() is accurate if you use the FontMetrics from the render
context.
If it is always accurate why it is not recommended in the new
documentation? Why we sug
then it looks like the charWidth()
should return "advance"
of some specific "advance", and getMaxAdvance() is "just" maximum
value of any possible
results from the charWidth().
On 4/22/20 12:49 pm, Philip Race wrote:
bug : https://bugs.openjdk.java.net/br
bug : https://bugs.openjdk.java.net/browse/JDK-8230672
webrev : http://cr.openjdk.java.net/~prr/8230672/
Loosen up the spec. a lot to reflect reality.
I considered deprecating the method but there isn't any easy replacement,
so it would just be annoying to old code.
This will clearly need a
Just problem listing one test on one platform
Bug: https://bugs.openjdk.java.net/browse/JDK-8243314
Change :
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -262,7 +262,7 @@
Bylokhov wrote:
Just one question, did we check the possibility to save the "invalid"
state in the graphics itself?
So if the transform of the graphics, or transform of the text will be
non-invertible then we just return immediately
On 4/16/20 4:05 pm, Philip Race wrote:
On 4/12/20
So if this is "always zero", for BufferedImage, why aren't we just
directly returning zero ?
I'm a bit on the fence about this wondering whether to submit a CSR here,
since a behavioural change is being introduced in order to conform to
the spec,
and there is some compatibility issue
get an outline and
then hand it off to be drawn but
the shape isn't something that you can see, probably because it was clipped.
So rather than relying on all that and hoping the checks are very useful.
-phil
Thanks,
Jay
On 11-Apr-2020, at 2:33 AM, Philip Race <mailto:philip.r...@oracle.
rt this bug is about synthetic bolding, nothing else.
-phil
Thanks,
Jay
On 16-Apr-2020, at 2:30 AM, Philip Race wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8233006
Webrev : http://cr.openjdk.java.net/~prr/8233006
The bug here is that the freetype function for synthesising bold is
+1
BTW your bug link goes to the wrong bug, should go here :
https://bugs.openjdk.java.net/browse/JDK-8195841
-phil.
On 4/13/20, 2:40 AM, Jayathirth D v wrote:
Hello All,
Please review the following fix for JDK 15:
Bug : https://bugs.openjdk.java.net/browse/JDK-8195841
sed for anything ..
+slot->metrics.vertAdvance += extra;
.. but freetype added it, so I did so too to be safe.
-phil.
On 4/15/20 2:00 pm, Philip Race wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8233006
Webrev : http://cr.openjdk.java.net/~prr/8233006
The bug here is that the freetyp
Bug : https://bugs.openjdk.java.net/browse/JDK-8233006
Webrev : http://cr.openjdk.java.net/~prr/8233006
The bug here is that the freetype function for synthesising bold is not
ready to handle rotation.
In the process I noticed it did not adjust the advance used by the
fractional metrics
Sorry for the resend - my mailer claimed it had failed !
-phil.
}
}
May be I am wrongly using TextLayout.draw() to check expected
behaviour after the change.
Please clarify.
Thanks,
Jay
On 10-Apr-2020, at 7:45 PM, Philip Race <mailto:philip.r...@oracle.com>> wrote:
Oh and if you do draw it, it still goes through the GV path so
nothing should
}
}
May be I am wrongly using TextLayout.draw() to check expected
behaviour after the change.
Please clarify.
Thanks,
Jay
On 10-Apr-2020, at 7:45 PM, Philip Race <mailto:philip.r...@oracle.com>> wrote:
Oh and if you do draw it, it still goes through the GV path so
nothing should
Could you describe here the ideas behind your fix and what the
implications are
1) I'm sure I've seen printers that describe the same paper size by
multiple names.
Why is it a problem here ? If it is because we have the same display
name, is that
just for known standard sizes ? Can we get the
change in Copyright year from 2015 to 2020.
oops.
-phil.
Thanks,
Jay
On 10-Apr-2020, at 7:53 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:
D**n copy/paste, yes you correctly inferred the webrev is at
// ie :
http://cr.openjdk.java.net/~prr/8242004/
<http://cr.open
o path where you usually share webrev's and found
http://cr.openjdk.java.net/~prr/8242004/
<http://cr.openjdk.java.net/%7Eprr/8242004/>
Thanks,
Jay
On 10-Apr-2020, at 12:49 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:
Any takers ?
-phil
On 4/3/20, 1:29 PM, Ph
Any takers ?
-phil
On 4/3/20, 1:29 PM, Philip Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242004
webrev: https://bugs.openjdk.java.net/browse/JDK-8242004
Several code paths can end up in the method shown in the bug report
with a non-invertible transform.
As much as possible
Bug: https://bugs.openjdk.java.net/browse/JDK-8242325
Webrev : http://cr.openjdk.java.net/~prr/8242325/
With the impending removal of the Solaris SPARC port, there is even less
point
than before to keeping around the VIS version of medialib, and versions of
the 2D rendering loops that call
I confess to not being 100% sure which one you thing is in some way
"unexpected".
I *think* you are complaining only about the large size rendering of
cambria in 3.png
BEFORE the fix and that it is equally blurry with or without the fix.
I don't have my usual tools handy to check but that
n
On 4/2/20 12:09 pm, Sergey Bylokhov wrote:
On 4/2/20 12:00 pm, Philip Race wrote:
Are we leaking the handle ? Looks that way to me ..
if certain fonts are missing.
Best regards
Christoph
*From:*2d-dev <2d-dev-boun...@openjdk.java.net> *On Behalf Of *Philip Race
*Sent:* Mittwoch, 18. März 2020 01:00
*To:* Sergey Bylokhov
*Cc:* 2d-dev <2d-dev@openjdk.java.net>
*Subject:* Re: [OpenJDK 2D-Dev] RFR: 8223935: PIT:
j
Bug: https://bugs.openjdk.java.net/browse/JDK-8223090
Webrev : http://cr.openjdk.java.net/~prr/8223090/
Removing obsolete dead code - it no longer has relevance.
The disableHinting flag was discarded by the callees anyway
-phil.
Yeah. Faster.
-phil.
On 4/4/20, 9:57 PM, Sergey Bylokhov wrote:
Hi, Phil.
Does the SolidTextRenderer have some benefits over AATextRenderer so
we have to use it by default on 10.13 on jdk15?
On 4/4/20 8:16 pm, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220150
Webrev
Bug: https://bugs.openjdk.java.net/browse/JDK-8220150
Webrev : http://cr.openjdk.java.net/~prr/8220150/
We are being returned grey glyphs when asking for B
The same is true for LCD, although they are a little different and not
the main problem.
The main problem is that when our software loops
Regards
Prasanta
On 01-Apr-20 7:37 AM, Sergey Bylokhov wrote:
On 3/31/20 5:42 pm, Philip Race wrote:
On 3/31/20 1:37 pm, Philip Race wrote:
The fix is in code used on Linux/Solaris and Windows only.
The Mac printing path is quite different and was not affected.
So are you misunderstanding my
bug: https://bugs.openjdk.java.net/browse/JDK-8242004
webrev: https://bugs.openjdk.java.net/browse/JDK-8242004
Several code paths can end up in the method shown in the bug report
with a non-invertible transform.
As much as possible, we can prevent them reaching here by checking in
the
Hmm ... I guess OpenPrinter doesn't fail often.
More of a concern is that I don't see where we (before or after this
change) call ClosePrinter
in the case of success.
We certainly don't want to close it here because acc to
f (alpha != 1.0
1905 || (rule != AlphaComposite.SRC
1906 && rule != AlphaComposite.SRC_OVER))
1907 {
1908 isCompositing = true;
1909 }
On 3/31/20 1:37 pm, Philip Race wrote:
The fix is in code used on Linux/Solaris and Windows only.
Th
bug: https://bugs.openjdk.java.net/browse/JDK-8240342
webrev : http://cr.openjdk.java.net/~prr/8240342/
The code that determines if we could print an image via platform APIs
was not checking for custom composites.
The fix is in code used on Linux/Solaris and Windows only.
The Mac printing path
as the problem manifests now only
in windows? linux-mac are working and as fast it can be.
I mean it was mentioned it takes 3-4 minutes in linux-mac and 30-odd
minutes in windows.
Regards
Prasanta
On 21-Mar-20 4:49 AM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
Bug: https://bugs.openjdk.java.net/browse/JDK-8232634
This test ICMColorDataTest.java takes a very long time on Windows and
still too long on other platforms.
It will be investigated as bug
https://bugs.openjdk.java.net/browse/JDK-8233028
In the mean time we will problem list it :
Fix:
diff
MROOT%\Fonts" instead of
"c:\\windows\\fonts"?
On 3/17/20 9:34 am, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
Webrev: http://cr.openjdk.java.net/~prr/8223935/
WindowsIndicFonts has been failing randomly depending on
whether a test system has the I
Bug: https://bugs.openjdk.java.net/browse/JDK-8223935
Webrev: http://cr.openjdk.java.net/~prr/8223935/
WindowsIndicFonts has been failing randomly depending on
whether a test system has the Indic fonts installed.
This updates the test to not fail on systems which don't have the expected
fonts
Note that JDK 14 GA's next Tuesday - 17th March 2020.
Also the place to file bugs is https://bugreport.java.com/bugreport/
This list is the place to propose a source code fix for an existing bug.
-phil.
On 3/12/20, 9:09 AM, Sergey Bylokhov wrote:
Hi,
As a first step, I suggest updating
I don't understand why you need to recheck that left > 0.
Nothing can change it between the while loop check and your check
while (left > 0) {
int nbytes = stream.read(block, off, left);
+if (nbytes == -1 && left > 0) {
+
OK. CSR is reviewed.
-phil.
On 3/4/20, 5:37 PM, Sergey Bylokhov wrote:
webrev and CSR are updated:
Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01
CSR: https://bugs.openjdk.java.net/browse/JDK-8240554
On 3/4/20 5:07 pm, Philip Race wrote:
I suggest changing + * The documentation
I suggest changing
+ * The documentation in this module includes links to overviews, tutorials,
+ * examples, guides, and other documentation. This is done for convenience.
+ * Information at these external resources is not part of JavaSE API
+ * Specification.
to
+ * The documentation in this
glyphInfo->topLeftX -= 1;
+ // WHY NOT ADD ?
+ glyphInfo->width += 1;
On 2/11/20 8:15 pm, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8238942
webrev: http://cr.openjdk.java.net/~prr/8238942/
As discussed in the bug, we are missing padding in the code that takes
an LCD gly
Bug: https://bugs.openjdk.java.net/browse/JDK-8238942
webrev: http://cr.openjdk.java.net/~prr/8238942/
As discussed in the bug, we are missing padding in the code that takes
an LCD glyph from freetype and caches it in the 2D glyph cache.
This padding is used in subpixel positioning with
Bug: https://bugs.openjdk.java.net/browse/JDK-8238721
Webrev : http://cr.openjdk.java.net/~prr/8238721/
-phil.
I'll do this for you.
-phil.
On 1/27/20, 1:10 AM, Dmitry Batrak wrote:
Thanks!
Now that that change has two +1's, would anyone be able to push it?
Best regards,
Dmitry Batrak
On Tue, Jan 21, 2020 at 8:05 AM Sergey Bylokhov
mailto:sergey.bylok...@oracle.com>> wrote:
Looks fine.
Bug: https://bugs.openjdk.java.net/browse/JDK-8224109
Webrev: http://cr.openjdk.java.net/~prr/8224109/
There have been at least a couple of reports on this problem which manifests
when using fractional metrics.
As noted in the bug eval
- we had the wrong sign for the y advance in this path
-
Is there a regression test ?
I don't see a noreg- label.
-phil.
On 1/9/20, 12:51 AM, Clemens Eisserer wrote:
Hi,
Please review the fix for bug 8235904 "Infinite loop when rendering
huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
The issue was caused by integer overflow
Hi,
I have checked and unfortunately I can't open this one, and honestly,
there's no reason for you to backport this, the issue only relevant for
some internal scripts we use.
-phil.
On 12/13/19, 12:13 AM, Langer, Christoph wrote:
Hi,
this week, change
OK, +1
-phil.
On 12/9/19, 11:15 AM, Sergey Bylokhov wrote:
On 12/9/19 10:23 am, Phil Race wrote:
How did this get found ? Is it a regression caused by some other bug
fix ?
I had run the test for the old bug, to check that we do not have new
regressions.
And found this one by running a
12/7/19 11:59 am, Philip Race wrote:
The equals() method was refactored a bit to make it easier to add
the extra tests, and some of the complexity is due to paranoia that
platName *might* be null .. although I don't think that should ever
be the case.
I think code can be simplified i
-ride
is still needed.
-phil.
On 12/7/19, 4:00 PM, Sergey Bylokhov wrote:
Hi, Phil.
A few years ago in JDK-8139176 we added a check for the "style" to the
CFont.equals(), probably this check can be added to the current method
in PhysicalFont and removed from the CFont?
On 12/7/19 11:59
Bug: https://bugs.openjdk.java.net/browse/JDK-8231556
Webrev: http://cr.openjdk.java.net/~prr/8231556/
The equals() method for the internal font "peer" looked at fullName.
This fix adds looking at the filename, (called platName in PhysicalFont).
Now we can distinguish the two versions of the
That is equivalent, just syntactic, so no issue there.
Any other reviewers ? This needs two.
-phil.
On 12/4/19, 2:39 PM, Sergey Bylokhov wrote:
Looks fine, the only suggestion is to use
Integer.getInteger(String nm, Integer val)
instead of
try{Integer.parseInt}catch{}
On 11/27/19 1:42
OK
-phil.
On 11/18/19, 5:34 PM, Yasumasa Suenaga wrote:
PING: Could you review it?
JBS: https://bugs.openjdk.java.net/browse/JDK-8220074
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/
I think it is a trivial change.
Yasumasa
On 2019/11/13 11:42, Yasumasa
OK. +1 from me.
-phil
On 11/11/19, 10:27 PM, Prasanta Sadhukhan wrote:
On 12-Nov-19 11:20 AM, Philip Race wrote:
It can't hurt can it ?
And a while (a good while) back an AWT developer claimed it was also
recommended for AWT ... I can't find that claim - too hard to locate.
So whilst we
.
On 11/11/19, 9:14 PM, Prasanta Sadhukhan wrote:
I felt it was not needed as it is awt test and it is not necessary to
call under EDT, unlike swing.
Regards
Prasanta
On 12-Nov-19 1:06 AM, Philip Race wrote:
Hi,
I don't understand why you make this change :-
-SwingUtilities.invokeAndWait
Hi,
I don't understand why you make this change :-
-SwingUtilities.invokeAndWait(() -> createAndShowGUI());
+createAndShowGUI();
-phil.
On 11/11/19, 3:14 AM, Prasanta Sadhukhan wrote:
Hi All,
Please review a testfix for an issue seen to be failing intermittently
in mach5
https://bugs.openjdk.java.net/browse/JDK-8214481
As you can see from reading there, this isn't really a bug, just a
change in behaviour,
and it is not clear if we want to restore the 8u behaviour.
I think I'd prefer another hint to be created although apps would need
to update
to it and run
Theoretically we've been going to fix this fragile test for weeks.
It tests something important or else I'd ditch it completely ..
Prasanta ?
-phil.
On 10/30/19, 7:14 AM, Langer, Christoph wrote:
Hi Matthias,
looks good, I definitely second that. Let's wait what 2d folks (Phil?)
have to
Bug: https://bugs.openjdk.java.net/browse/JDK-8227324
Webrev: http://cr.openjdk.java.net/~prr/8227324/
A patch update from 2.10.0 to 2.10.1.
Some refactoring and some bug fixes.
Builds fine with --use-freetype=bundled
-phil.
for the pre-defined instances held in static
variables of the class
>and those live for the life of the VM so will never be freed ...
-phil.
BTW do we have an option to mark this "finalize" as forRemoval=true or
just delete it?(example JDK-8159009/JDK-8212198)
On 10/11/19 2:01 pm, Ph
PS ..
BTW do we have an option to mark this "finalize" as forRemoval=true or
just delete it?(example JDK-8159009/JDK-8212198)
This will be for a backport, so that would be inappropriate even if I
wanted to address that now ..
-phil.
Bug: ICC_Profile has un-needed, not-empty finalize method
Webrev: http://cr.openjdk.java.net/~prr/8175984/
This is a native memory utilisation problem due to delay in collecting and
freeing ICC_Profiles and their associated classes and data.
The color management engine is native code and
Ok by me.
-phil
On 10/10/19, 11:34 PM, Prasanta Sadhukhan wrote:
Hi Phil, Sergey
Then, is http://cr.openjdk.java.net/~psadhukhan/8223158/webrev.2/ good
to check-in?
Regards
Prasanta
On 11-Oct-19 2:28 AM, Sergey Bylokhov wrote:
On 10/10/19 1:35 pm, Phil Race wrote:
> I guess at a minimum
I think this needs a little bit more explanation first.
Systems without fontconfig ... meaning without libfontconfig.
So does that mean you just can't find fonts or have none installed ?
If you have fonts installed and have a custom fontconfig.properties file
for AIX
which references those, then
1) This is an RFE, not a bug.
2) Does this font exist on Windows 7 ?
3) This cannot be backported since the older JDK releases will not
support it.
-phil.
On 10/3/19, 8:57 AM, Alexey Ivanov wrote:
Any volunteers to review?
On 25/09/2019 20:38, Alexey Ivanov wrote:
Hello,
Please review
Why is this sent to swing-dev ? That's completely the wrong list.
You want 2d-dev. I'll am replying on 2d-dev not swing-dev.
I wonder why I don't see this when I have my Mac closed and connect to
an external monitor ?
What is special here ?
> Now, when the main display is closed, the
Looks fine. getAllConfigs() already throws OOME in a couple of places so
in theory a caller should already be ready to handle that. Mainly I mean
that there shouldn't be any further JNI calls with a pending exception ...
-phil.
On 9/25/19, 12:39 AM, Baesken, Matthias wrote:
Hello, please
OK. Approved by me .. but .. it would be good if you can point out any
other cases
where you think we can compatibly make changes to get rid of the need
for suppressing this new warning.
-phil
On 9/23/19, 12:54 PM, Joe Darcy wrote:
Hi Phil,
On 9/22/2019 1:25 PM, Philip Race wrote
All looks good to me.
-phil
On 9/24/19, 11:37 AM, Alexey Ivanov wrote:
Hello,
Please review the following simple fix for JDK 14:
bug: https://bugs.openjdk.java.net/browse/JDK-8231144
webrev: http://cr.openjdk.java.net/~aivanov/8231144/webrev.00/
docs:
-with-resources construct will
do. It'll take care that the underlying filestream gets promptly
closed after the scanner is done.
Are you ok with it? I'd push it to the client repo then.
Best regards
Christoph
*From:*Philip Race
*Sent:* Freitag, 20. September 2019 23:28
*To:* Langer, Christoph
*Cc
+@SuppressWarnings("serial") // Not statically typed as Serializable
So is the comment being used to distinguish this overloading of what "serial"
means ?
Why not introduce a new warning category ?
Randomly looking at
src/java.desktop/share/classes/java/awt/Container.java
@@
logging when
reading the fontconfig info file
>Before I, or anyone else, starts to look at or comment on this,
>can you instead post to the correct list : 2d-dev.
Sure!
Best regards, Matthias
*From:*Philip Race <mailto:philip.r...@oracle.com>>
*Sent:* Dienstag, 9. Juli 2019
It should. Although it hasn't exactly baked in 14 yet.
-phil.
On 9/4/19, 4:42 PM, Bill York wrote:
Thanks, it looks like you made the change here:
https://hg.openjdk.java.net/jdk/client/rev/07556f8cd819
Do you know if this change will work with Java 8?
Bill
On 8/24/19, 6:22 PM, "Sergey
+1 from me. Looks the same as the FX fix modulo some moving things around.
-phil.
On 7/29/19, 12:56 AM, Laurent Bourgès wrote:
Hi,
Please review this bug fix for the Marlin renderer (introduced in
JDK11.0.2):
JBS: https://bugs.openjdk.java.net/browse/JDK-8228711
webrev:
Looks OK.
-phil.
On 7/18/19, 6:01 AM, Baesken, Matthias wrote:
Hello, please review this very small fix .
Currently we assign NULL two times in gtk2_interface.c to gint values.
This leads to warning like this (xlc16 / clang) :
In that case just delete the comments and the commented out code ...
-phil.
On 7/12/19, 3:12 PM, Brian Burkhalter wrote:
I think I'd be more inclined to make the code at 970 like that at 1036.
Can’t do this exactly as drawImageBGR at 903 does not throw a
PrinterException. Have to use
Hi,
Regarding all the touches on the desktop module
1) awt-dev isn't the only list, you should have included swing-dev and
2d-dev at least
2) I am wondering what client testing you propose to do to verify this ?
3) I've spent spare time over a number of months trying to decrease
unnecessary
CK package.
If this "noreg-jck" label creates problems, I can remove it at all.
Thank you,
Anton
On 11/07/2019 15:51, Philip Race wrote:
One more thing I just realised you should do here is de-problem list
the regression test that fails ... after verifying it now works,
updating it wi
One more thing I just realised you should do here is de-problem list
the regression test that fails ... after verifying it now works,
updating it with this bug ID.
And you can remove that noreg-jck label as a consequence.
-phil.
On 7/11/19, 7:35 AM, Philip Race wrote:
In such cases I like more
In such cases I like more than to be told "it would apply cleanly" but
also to see
that you actually prepared the webrev against 13. This is more certain
and ensures that when the fix is approved you don't accidentally push it
to the wrong repo. You have to go clone 13 and apply the patch there
Looks ok to me too, but I think awt-dev (added) is the most appropriate
email list since this is AWT Robot code.
-phil.
On 7/5/19, 1:51 AM, Prasanta Sadhukhan wrote:
looks ok to me but the review should have been done in swing-dev alias.
Regards
Prasanta
On 04-Jul-19 6:38 PM, Alexey Ushakov
I thought we had the checks for null in doCompare there for a reason.
Arrays.sort won't be very happy with a null element.
You said in the first review email of the v0 webrev :
> Arrays.equals() accepts null parameters and null elements in the
arrays and always returns the correct result.
files, I have created comparison
table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf
<http://cr.openjdk.java.net/%7Ejdv/8225160/file_compare.rtf>.
Thanks,
Jay
On 19-Jun-2019, at 6:01 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:
Hi,
First
These comm
Hi,
I am still looking for a code review on this - needed today !
-phil.
On 6/5/19, 11:43 AM, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8217731
webrev: http://cr.openjdk.java.net/~prr/8217731/
This is intended to "help" but cannot completely cure, with
some of the
1) I think this should be sent to the swing list, swing-dev since these
are swing demos AND there's a change in Swing product code.
2) Please *subscribe* to the lists before posting, else your mail will
be blocked
3) Please sign and return the OCA to make contributions.
These changes are
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 it with the bug id?
See
m.
I welcome any suggestions or comments.
Thanks,
Toshio Nakamura
- Original message -
From: Jayathirth Rao
<mailto:jayathirth@oracle.com>
To: Toshio 5 Nakamura
<mailto:toshi...@jp.ibm.com&g
l Race wrote:
If you try to print when there is no printer the behavior is not
strictly specified.
-Phil.
On May 29, 2019, at 3:25 PM, Sergey Bylokhov
wrote:
On 29/05/2019 15:16, Philip Race wrote:
It doesn't hang there. It hangs in print().
I guess it is even more strange, it hangs when tries to
It doesn't hang there. It hangs in print().
-phil.
On 5/29/19, 3:17 PM, Sergey Bylokhov wrote:
On 29/05/2019 14:09, Phil Race wrote:
think the mystery is not why it times out now, but why it did not do
so earlier.
But I assume it if the system does not have the printer then
No other comments so far so here's that update :
http://cr.openjdk.java.net/~prr/8224778.1/
-phil.
On 5/24/19, 2:41 PM, Philip Race wrote:
Yes, I just copied that line + edited it.
I can update both lines if that is what you are asking but I'll wait a
little to see
if there are any other
Yes, I just copied that line + edited it.
I can update both lines if that is what you are asking but I'll wait a
little to see
if there are any other comments first.
-phil.
On 5/24/19, 2:16 PM, Erik Joelsson wrote:
Hello Phil,
Patch looks good, but the curly braces look weird in a makefile.
Ah yes .. I see. So this looks fine.
I assume you did some testing but I can't imagine what problems
this fix would cause.
-phil.
On 5/14/19, 4:25 PM, Sergey Bylokhov wrote:
I have dropped the "checkSize" parameter from revalidate() method, it
was always "true"
On 14/0
Why is it not still using checkSize for that case, like this :-
if (checkSize&& ((getWidth() != width || getHeight() != height))
4256 || drawBuffer == null) {
4257 // component has been resized or the peer was recreated;
4258 // recreate the
I am not sure how important this clean up is but since you've done it ..
replacing "".equals(foo) wth foo.isEmpty(()
isn't equivalent but the cases I saw where you did are either
foo == null || [!]foo.isEmpty()
eg :
-if (fontName == null || "".equals(fontName)) {
+if (fontName ==
On 4/28/19, 8:25 AM, Peter Harvey wrote:
Apologies if this is not the correct channel for this email.
It is, but if you want to send any more emails to this list, you will
need to subscribe.
From what I can tell, Freetype 2.7 contained a change in hint
processing that led to poorer
hio 5 Nakamura"
Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>
To: Philip Race
Cc: 2d-dev <2d-dev@openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for
East Asian countries cannot belong to CompositeFont
Date: Mon, M
101 - 200 of 643 matches
Mail list logo
