[Bug swing/28027] Wrong clip region in Swing repaints - overwrites other components

[hendrich at informatik dot uni-hamburg dot de]

------- Comment #10 from hendrich at informatik dot uni-hamburg dot de  
2006-06-15 13:45 -------
Subject: Re:  Wrong clip region in Swing repaints - overwrites other components

> The problem here is that double buffering is disabled for the RubberbandTest
> component, so the call to paintImmediately() ends up painting on the screen
> directly. 

Well, drawing the rubberband directly is the whole idea of this component
(which has worked fine on Sun since JDK 1.1)... 

My circuit simulator also uses direct painting during animation. It is
usually much faster to bitblt a small area of (static) backbuffer and
then to draw animated objects on top of this, instead of always updating
the backbuffer (all objects) and then blitting the buffer.


> The only explanation that I can make up of this and which makes sense is that
> a component can only be not-doublebuffered when all of it's parents are not
> doublebuffered too. Otherwise the backbuffer and screen would not come into
> sync and we see that flickering that we see.

Is there some documentation about the current repaint strategy in Swing?
The source code for RepaintManager and the GTK stuff is pretty involved,
and not too helpful in this regard...

I always thought that the isDoubleBuffered() method was respected by 
Swing, but I never cared to check what Sun does internally. 

1. JComponent ------------------------> Swing Backbuffer -> screen    
2. JComponent -> internal backbuffer -> Swing backbuffer -> screen
3. JComponent -> internal backbuffer ---------------------> screen

My understanding was that "normal" components use strategy (1). 
My component definitely needs to manage its own backbuffer, and I thought
that with isDoubleBuffered=false I would get (3) and avoid the extra
useless copying involved with isDoubleBuffered=true and (2).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28027