This patch (committed) fixes some endless loops reported by FindBugs:
2006-05-18 David Gilbert [EMAIL PROTECTED]
* gnu/java/awt/print/JavaPrinterGraphics.java
(drawImage(Image, int, int, Color, ImageObserver)): Fix endless loop,
(drawImage(Image, int, int,
Hi Robert,
Cool that this is now fixed.
Well, it's not complete yet. This is why I still didn't close the PR.
However, there is one (minor IMO) problem left. As it is now, the
positionMarks array is never cleaned up, that means that marks are kept
there, even if their corresponding
Hi,
I committed the attached optimization to the URL construction in
JarURLLoader. Not really to improve performance, but to make Google's
new Google Web Toolkit shell startup (it's broken and does an identity
comparison on the string returned by URL.getProtocol()).
Regards,
Jeroen
2006-05-18
Roman Kennke wrote:
Hi Audrius,
I finally find some time to look into your optimizations. Unfortunately
I don't think they are correct at all. (This is why I come to this at
all - painting seems broken in some special cases, like when you have a
textfield and open a menu that overlaps the
Hi Audrius,
first of all, I didn't want to offend you. Sorry if you feel like this.
* javax/swing/RepaintManager.java (addDirtyRegion):
If there is a lightweight parent, recursively add the corresponding
region of the parent instead.
This is not ok. Some easy tests
Roman Kennke wrote:
I don't think they are correct at all. (This is why I come to this at
all - painting seems broken in some special cases, like when you have a
textfield and open a menu that overlaps the textfield, the menu gets
damaged by the textfield painting.)
I have reverted all
This changes breaks the painting, as I explained, since it must be
scanned up to the root to determine if some other component overlaps the
component to be painted. If you try out a text editor (say, Notepad.jar
from Sun's demo programs), and open up a menu that overlaps the
JTextArea, the
Roman Kennke wrote:
Hi list, hi Audrius,
I looked a little over the recent JComponent/RepaintManager changes.
Surely, this patch is great. There are no redundant repaints, so the
frame moving and resizing remains fast. The algorithm is now more
sophisticated than the previously uses force
Hiyo,
Lets discuss this separately. Though I'm curious in which way the
blitting was broken.
if (canBlit isPaintRoot) in JViewport.paintBlit. Sorry, I thought
this is your code. But it is really not working is isPaintRoot is false,
I tried this.
Yes, I've written this part
I improved the GapContentPosition stuff a little, now lumping marks
together into one mark when they become equal. This does still not 100%
solve the bug 26368, but we get nearer.
2006-05-18 Roman Kennke [EMAIL PROTECTED]
PR 26368
* javax/swing/text/GapContent.java
Hi,
Am Donnerstag, den 18.05.2006, 16:11 +0200 schrieb Audrius Meskauskas:
Roman Kennke wrote:
Hi list, hi Audrius,
I looked a little over the recent JComponent/RepaintManager changes.
Surely, this patch is great. There are no redundant repaints, so the
frame moving and resizing
Hi there,
This is surely required, no doubt about this. The table must support
variable row heights and it did not. But now when scrolling from top to
bottom, the height of the repaint region occasionaly turns negative:
java.awt.Rectangle[x=0,y=465,width=34,height=-450]
This is strange.
This patch implements support for INDEX.LIST handling in a
URLClassLoader.
It works by modifying the JarURLLoader to understand this index and
to add it to other loaders which it creates.
I also removed the cache of URLLoaders from URLClassLoader. I don't
think this cache provides much value,
Hi there again,
This is surely required, no doubt about this. The table must support
variable row heights and it did not. But now when scrolling from top to
bottom, the height of the repaint region occasionaly turns negative:
java.awt.Rectangle[x=0,y=465,width=34,height=-450]
Now
Ugh, I forgot to remove the old statement.
2006-05-18 Roman Kennke [EMAIL PROTECTED]
* gnu/java/awt/peer/gtk/GdkGraphics.java
(clipRect): Removed old intersection statement.
/roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of
Hi again,
I think, the blitting is broken again, because width=450,height=426
means that the whole table should be repainted.
Another part of the problem is the following stacktrace that I get when
intercepting repaint() in JTable (below). You can see that the painting
of the cells goes
I implemented and documented ShapeGraphicAttribute.
I have also committed a mauve test for it.
2006-05-18 Lillian Angel [EMAIL PROTECTED]
* java/awt/font/ShapeGraphicAttribute.java:
Documented entire class.
(ShapeGraphicAttribute): Initialized bounds field.
Hi,
this is the first fix to make painting of JButtons which are direct childs of a
JToolBar correct.
I found out that those button will not draw their extra thick border when the
mouse is hovering above them. I fixed that in the MetalBorder.ButtonBorder
class.
Additionally I found out that the
Hi,
the attached patch makes it possible that one can click and *hold* on a JButton
A, move over to other buttons without setting their rollover state to true and
come back to A.
This is important because in the OceanTheme setting the rollover flag to true
makes the button paint a thick border or
Lillian == Lillian Angel [EMAIL PROTECTED] writes:
Lillian - public static final int BOTTOM_ALIGNMENT = -2;
Lillian + public static final int BOTTOM_ALIGNMENT = - 2;
This is kind of weird.
If there is an eclipse formatter setting for this, we should change
it.
If not, we should file a
On Thu, 2006-05-18 at 12:59 -0600, Tom Tromey wrote:
Lillian == Lillian Angel [EMAIL PROTECTED] writes:
Lillian - public static final int BOTTOM_ALIGNMENT = -2;
Lillian + public static final int BOTTOM_ALIGNMENT = - 2;
This is kind of weird.
If there is an eclipse formatter setting
I implemented two unimplemented functions.
2006-05-18 Lillian Angel [EMAIL PROTECTED]
* java/awt/font/GlyphMetrics.java
(getLSB): Implemented.
(getRSB): Implemented.
Index: java/awt/font/GlyphMetrics.java
Hi,
I completed ImageInputStreamImpl and MemoryCacheImageInputStream. Though all
but one of the methods had implementations, they were very buggy. I've
committed a new test case to Mauve to ensure that these classes are now correct.
This patch brings the pure Java JPEG decoder closer to a
[EMAIL PROTECTED] wrote:
Baseline from: Tue May 16 14:20:57 UTC 2006
New fails:
FAIL: gnu.testlet.javax.swing.DefaultButtonModel.setArmed (number 10)
FAIL: gnu.testlet.javax.swing.DefaultButtonModel.setArmed (number 11)
FAIL: gnu.testlet.javax.swing.DefaultButtonModel.setArmed
Making installcheck in scripts
make[2]: Entering directory
`/home/cpdev/Nightly/classpath/build/classpath-0.92-pre/_build/scripts'
make[2]: Nothing to be done for `installcheck'.
make[2]: Leaving directory
`/home/cpdev/Nightly/classpath/build/classpath-0.92-pre/_build/scripts'
Making
Making installcheck in scripts
make[2]: Entering directory
`/home/cpdev/Nightly/classpath/build/classpath-0.92-pre/_build/scripts'
make[2]: Nothing to be done for `installcheck'.
make[2]: Leaving directory
`/home/cpdev/Nightly/classpath/build/classpath-0.92-pre/_build/scripts'
Making
Baseline from: Thu May 18 10:39:03 UTC 2006
Regressions:
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode-native test
FAIL: Thread_Sleep -O3 output - bytecode-native test
FAIL: Thread_Sleep -O3 output - source compiled test
FAIL: Thread_Sleep -findirect-dispatch output -
make[3]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make all-am
make[4]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
make[3]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make all-am
make[4]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
make[3]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make all-am
make[4]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
make[3]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make all-am
make[4]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
make[3]: Leaving directory
`/home/mkoch/src/classpath/build/classpath-20060519/_build/external/relaxngDatatype'
make[3]: Entering directory
`/home/mkoch/src/classpath/build/classpath-20060519/_build/external'
make[3]: Nothing to be done for `installcheck-am'.
make[3]: Leaving directory
make[3]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make all-am
make[4]: Entering directory
`/home/cpdev/Nightly/gcc/build/i386-pc-linux-gnu/boehm-gc/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
Hi Robert,
On Mon, 2006-05-15 at 09:06 +0200, Robert Schuster wrote:
man 2 accept says that the socket created by accept() has the same
properties
as the socket which was used in the accept call.
Is it possible that in Java the created socket should have default properties
here instead?
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Roman Kennke [EMAIL PROTECTED]06/05/18 13:53:24
Modified files:
javax/swing: KeyboardManager.java
. : ChangeLog
Log message:
2006-05-18 Roman Kennke
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Roman Kennke [EMAIL PROTECTED]06/05/18 14:16:11
Modified files:
javax/swing/text: GapContent.java
. : ChangeLog
Log message:
2006-05-18 Roman Kennke
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Roman Kennke [EMAIL PROTECTED]06/05/18 14:17:52
Modified files:
javax/swing: JComponent.java RepaintManager.java
. : ChangeLog
Log message:
2006-05-18
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Roman Kennke [EMAIL PROTECTED]06/05/18 15:21:40
Modified files:
javax/swing: CellRendererPane.java
. : ChangeLog
Log message:
2006-05-18 Roman Kennke
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Lillian Angel [EMAIL PROTECTED] 06/05/18 15:50:47
Modified files:
. : ChangeLog
java/awt/font : ShapeGraphicAttribute.java
Log message:
2006-05-18 Lillian
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Robert Schuster [EMAIL PROTECTED] 06/05/18 17:28:08
Modified files:
java/awt : LightweightDispatcher.java
. : ChangeLog
Log message:
2006-05-18 Robert
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Lillian Angel [EMAIL PROTECTED] 06/05/18 18:56:24
Modified files:
. : ChangeLog
java/awt/font : GraphicAttribute.java
Log message:
2006-05-18 Lillian Angel
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Lillian Angel [EMAIL PROTECTED] 06/05/18 19:30:09
Modified files:
. : ChangeLog
java/awt/font : GlyphMetrics.java
Log message:
2006-05-18 Lillian Angel
42 matches
Mail list logo
