Well, yes, I'm afraid so. On Nimbus, however, I don't see
any degradation, and it seems that after switching from Nimbus
to Metal or GTK SwingSet2 is more responsive.
But the fix is not in this PIT, is it?
-yan
On 07/01/2015 06:27 PM, Phil Race wrote:
BTW I meant to send email on this but yesterday whilst doing
manual testing of the final PIT builds on 64 bit Linux I still saw one
CPU core
max out on the HTMLEditor test in SwingSet2.
I think it was GTK L&F but I do not remember for sure ..
I suspect it is actually all of them.
I did not see the same on OS X (for example).
Yuri ??
-phil.
On 7/1/15 7:17 AM, Pete Brunet wrote:
That fixed it. Thanks Semyon.
On 7/1/15 8:25 AM, Pete Brunet wrote:
Thanks Semyon! I'll give it a try. -Pete
On 7/1/15 2:29 AM, Semyon Sadetsky wrote:
Hi Pete,
I heard that you got performance issue in b68 connected to text
components.
It can be caused by https://bugs.openjdk.java.net/browse/JDK-8098835.
The next patch can help:
---
old/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java
2015-06-16 20:20:42.678311800 +0300
+++
new/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java
2015-06-16 20:20:42.136257600 +0300
@@ -971,7 +971,7 @@
((AbstractDocument)doc).readLock();
}
try {
- d.width = (int) rootView.getMinimumSpan(View.X_AXIS) +
i.left + i.right;
+ d.width = (int) rootView.getMinimumSpan(View.X_AXIS) +
i.left + i.right + caretMargin;
d.height = (int) rootView.getMinimumSpan(View.Y_AXIS) +
i.top + i.bottom;
} finally {
if (doc instanceof AbstractDocument) {
@@ -996,7 +996,7 @@
}
try {
d.width = (int) Math.min((long)
rootView.getMaximumSpan(View.X_AXIS) +
- (long) i.left + (long) i.right,
Integer.MAX_VALUE);
+ (long) i.left + (long) i.right +
caretMargin, Integer.MAX_VALUE);
d.height = (int) Math.min((long)
rootView.getMaximumSpan(View.Y_AXIS) +
(long) i.top + (long) i.bottom,
Integer.MAX_VALUE);
} finally {
@@ -1027,7 +1027,7 @@
Insets insets = editor.getInsets();
alloc.x += insets.left;
alloc.y += insets.top;
- alloc.width -= insets.left + insets.right;
+ alloc.width -= insets.left + insets.right + caretMargin;
alloc.height -= insets.top + insets.bottom;
return alloc;
}
--Semyon
On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote:
I think './common/bin/hgforest bisect ...' should do the trick then.
On 29.06.2015 7:30, Phil Race wrote:
Just be aware that you will need to apply the same to each repo in
the JDK forest.
Else it will very likely not build. Eg the jdk repo must be in sync
with the top-level repo.
-phil.
On 6/28/15 5:59 PM, Pete Brunet wrote:
Thanks Vadim, I'll give it a try. -Pete
On 6/28/15 3:24 PM, Vadim Pakhnushev wrote:
Pete,
Actually you should use hg bisect command to do this.
First, you mark 2 revisions you now as bad and good, like this:
hg bisect --good jdk9-b67
hg bisect --bad tip
The last command will bisect the list of changesets and update the
repo to some changeset in between.
Then you build the repo, test it and mark it as either bad or good:
hg bisect --bad
This will advance the current changeset and you test it again until
you arrive at the 'first bad' changeset.
See here for reference: https://www.selenic.com/hg/help/bisect
Hope this helps,
Vadim
On 28.06.2015 18:15, Pete Brunet wrote:
Looks like I can use hg update to accomplish this, i.e. hg update
to the
rev that is b67 and then hg update to each possibly offending rev
of the
jdk repo. Sound right?
On 6/26/15 4:13 PM, Pete Brunet wrote:
Hi, I found a problem on b68 and there are a half dozen possible
changesets that could be responsible. What is the best way to
do the
process of elimination. It seems like the right approach would
be to
start with b67 and then add changesets one at a time until the
problem
surfaces. Is that right or is there a better way?
Starting with a fresh current clone what are the steps to strip
back to
b67 and then to add changesets?
This will be in the jdk branch of the forest.
Thanks, Pete
