On Fri, 2006-02-10 at 01:00 +0100, Mark Wielaard wrote:
> Hi,
>
> While debugging some awt gtk+ peer issues I noticed that we always route
> repaint events through 2 queues. First we create a Timer and put it in
> there. Second we put it in the actual system event queue. If the repaint
> is requested immediately that is overkill. And looking at a couple of
> sample programs it looks like delayed repaints are not that often
> requested at all. So this patch defers the creation of the Timer till
> the first time a delayed repaint request is actually made. And it
> immediately posts the repaint event to the system event queue if no
> delay is asked for.
>
> 2006-02-09 Mark Wielaard <[EMAIL PROTECTED]>
>
> * gnu/java/awt/peer/gtk/GtkComponentPeer.java (repaintTimer):
> Removed field.
> (repaint): Immediately post to queue when tm <= 0, otherwise call
> RepaintTimerTask.schedule().
> (RepaintTimerTask): Make static.
> (RepaintTimerTask.repaintTimer): New static final field.
> (RepaintTimerTask.awtComponent): New field.
> (schedule): New static method.
>
> OK to commit?
It looks like you left some debugging code in:
+ System.err.println("UPDATE: " + awtComponent);
+ Thread.dumpStack();
Other than that this looks good.
Tom
>
> Cheers,
>
> Mark
