I added a switch per system property for globally disabling double
buffering for Swing. This might be useful for debugging and (ATM) can
only be achieved by actually calling
RepaintManager.setDoubleBufferedEnabled(false), which means you have to
modify your application code.
2006-11-14 Roman
This is a cleanup. I disabled some parts of RepaintManager some time ago
because I suspected that it doesn't improve painting performance, and
now I rip these parts out. This also means some slight performance
improvement, because the rectangle translation is done on the fly.
2006-08-17
This fixes a Mauve tests. Besides that it hasn't much impact as these
methods aren't used in Swing itself.
2006-07-26 Roman Kennke [EMAIL PROTECTED]
* javax/swing/RepaintManager.java
(markCompletelyDirty): Add dirty region with Integer.MAX_VALUE
for the component.
While debugging a severe performance problem with one app, I noticed
that our RepaintManager validates far too much. I observed how the RI
behaves and found that:
- only components with a validateRoot are validated
- only components that are displayable and visible and that have visible
parents
This fixes a thinko of mine.
2006-06-15 Roman Kennke [EMAIL PROTECTED]
PR 28037
* javax/swing/RepaintManager.java
(blitBuffer): Substract coordinates the other way around.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are
In the RepaintManager we used to merge regions of different components
to one when blitting the buffer on the screen. However, this proves to
cause painting artifacts. This happens when different distinct regions
of the screen get updated simultanously (especially when using Timers
and/or multiple
While working on the X11-AWT peers, I noticed that our RepaintManager
gets into trouble when it is called from different threads (which is
legal, despite the common mantra that Swing is not thread-safe. The
RepaintManager is the core component in the not-thread-safe design of
Swing and is actually
In the RepaintManager we are using the Graphics.drawImage() method, that
takes 11 parameters to paint a part of the buffer to a part of the
screen. Looking at the native code this seems rather inefficient (there
are 1-2 temporary images created there, a scaling is performed etc,
which is all
According to the specs, Graphics.getClip(Bounds) may return null when no
clip is set. I added appropriate checks to the RepaintManager to avoid
NPEs in such situations.
2006-03-03 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicHTML.java
(HTMLRootView): New inner
Hi,
I observed some occasional problem with the RepaintManager vs painting.
Sometimes the RepaintManager simply crashes in Graphics.drawImage with
an assertion failure. This was caused by negative dx and dy offsets
(from JViewport I guess). This patch fixes this by intersecting the
dirty area
In RepaintManager.addInvalidComponent we should really also consider the
component itself and ask if it is a validateRoot. Up to now we started
with the component's parent.
2006-02-22 Roman Kennke [EMAIL PROTECTED]
* javax/swing/RepaintManager.java
(addInvalidComponent): Also
I once more optimized the Swing RepaintManager to limit the amount of
painting work that is carried out by Swing. While observing painting
behaviour I noticed that sometimes (especially with overlapping
components) the painting is carried out in a 2-step manner, which
results in strange artifacts
I fixed a condition in RepaintManager.validateInvalidComponents() to
avoid an NPE.
2006-01-10 Roman Kennke [EMAIL PROTECTED]
* javax/swing/RepaintManager.java
(validateInvalidComponents): Fixed condition to avoid NPE.
/Roman
Index: javax/swing/RepaintManager.java
Hi there,
I fixed a bug in the RepaintManager. Until now, the RepaintManager
iterated over all invalid components and simply called validate() on it.
However, it should not validate() the invalid components directly, but
instead search the component's validate root (see
Am Samstag, den 19.11.2005, 19:09 +0100 schrieb Mark Wielaard:
Hi Roman,
On Mon, 2005-11-14 at 12:52 +, Roman Kennke wrote:
+ /**
+ * The current repaint managers, indexed by their ThreadGroups.
+ */
+ static HashMap currentRepaintManagers;
Isn't this a potential memory
I forgot the patch. Here it comes now.
/Roman
Am Montag, den 21.11.2005, 15:02 +0100 schrieb Roman Kennke:
Am Samstag, den 19.11.2005, 19:09 +0100 schrieb Mark Wielaard:
Hi Roman,
On Mon, 2005-11-14 at 12:52 +, Roman Kennke wrote:
+ /**
+ * The current repaint managers,
Hi Roman,
On Mon, 2005-11-14 at 12:52 +, Roman Kennke wrote:
+ /**
+ * The current repaint managers, indexed by their ThreadGroups.
+ */
+ static HashMap currentRepaintManagers;
Isn't this a potential memory leak? Maybe there are not many
ThreadGroups in an application ever. But it
Am Samstag, den 19.11.2005, 19:09 +0100 schrieb Mark Wielaard:
Hi Roman,
On Mon, 2005-11-14 at 12:52 +, Roman Kennke wrote:
+ /**
+ * The current repaint managers, indexed by their ThreadGroups.
+ */
+ static HashMap currentRepaintManagers;
Isn't this a potential memory
The RepaintManagers static access methods currentManager() and
setCurrentManager() should manage the RepaintManager instances by the
calling thread's ThreadGroup instead of using one global instance for
everything. I implemented this in the following patch.
2005-11-14 Roman Kennke [EMAIL
gjdoc was complaining about a character in a comment in this file, and when I looked
at it using Eclipse the on screen display was a little corrupted, so I replaced the
character:
2005-10-27 David Gilbert [EMAIL PROTECTED]
* javax/swing/RepaintManager.java
20 matches
Mail list logo
