This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Change to coalescePaintEvents method's heuristics


On Mon, 2004-01-19 at 13:47, David Jee wrote:
> Here is a patch which changes the heuristics of coalescePaintEvents
> method in java.awt.Component class.  The following is a rather
> long-winded explanation for the patch:
> 
> The old heuristics dictated that two paint areas will be merged if the
> union of the areas is less than twice that of the sum of the areas. 
> This has the side-effect of repainting regions that were not originally
> intended to be repainted, as illustrated below:
> 
> +----+                                +---------+
> |    |                                |     ####|
> |    +----+    will be merged into    |         |
> +----|    |                           |         |
>      |    |                           |####     |
>      +----+                           +---------+
> 
> In the diagram above, # denotes areas not originally intended to be
> repainted.  In the case that we are repainting a Container, if any
> heavyweight components exist in the areas denoted by #, they would be
> over-painted with the Container's background color and would not be
> repainted again.
> 
> We could introduce a mechanism to explicitly and forcefully repaint the
> erased heavyweight components, but that seems like a hack to me.  (I
> could be wrong on this.  Comments are welcome.)

The mechanism to force a peer to repaint itself is already there, though
our implementation is probably broken.  The ComponentPeer interface
declares paint and repaint methods.  GtkComponentPeer does implement
these but they currently just call back to Component.  To finish the
implementation, you may need to handle paint events in
GtkComponentPeer.handleEvent (which is currently empty), and have it
call native methods to request that GTK redraw the backing widget.  You
may need to use gtk_widget_queue_draw_area or one of the corresponding
GDK region-invalidating functions.

> 
> Instead, I propose that we change the heuristics so it only merges the
> two areas if the union of the areas is less than or equal to the sum of
> the areas.  This ensures that we only repaint areas that were originally
> intended to be repainted.
> 
> This heuristic change should be a temporary solution.  In the future, we
> should implement a complex and efficient repaint area object (like Sun's
> RepaintArea) that will allow us to coalesce paint areas into
> non-rectangular shapes.  For public references to Sun's RepaintArea
> object, see:
> http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Component.html#coalesceEvents(java.awt.AWTEvent,%20java.awt.AWTEvent)
> http://java.sun.com/j2se/1.3/docs/guide/awt/enhancements.html#coalescing
> 

Regardless of the specific coalescing algorithm used here, repainting a
component and its children should be robust in the face of bad guesses
by the heuristic.  So I think we do need to properly implement
repainting of heavyweight components.

Tom



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]