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
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
