bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug swing/28027] New: Wrong clip region in Swing repaints - overwrites


From: hendrich at informatik dot uni-hamburg dot de
Subject: [Bug swing/28027] New: Wrong clip region in Swing repaints - overwrites other components
Date: 14 Jun 2006 09:14:23 -0000

This is my follow-up bug report to swing/27833, regarding clip region issues
observed with two of my test applications (jfig and Hades, both using the same
FigSwingCanvas component for their main display).

So far I have failed to come up with a simple testcase, but I do have
additional
information:

How to reproduce the bug:

1. Download  
   http://tams-www.informatik.uni-hamburg.de/applets/hades/archive/hades.jar
2. Run jamvm -jar hades.jar
3. Select menu > help > demos > clockgen
4. Wait two seconds until the demo begins

5a. Try to open a menu
6a. I personally like menu > layers the best: somehow two different parts of
the 
    menu are redrawn when the LED connected to the upper clock generator is 
    updated :-)

5b. Use a mouse-click to ensure that the main canvas has the keyboard focus
6b. Type the 'z' key to initiate a zoom-out operation.
7b. Observe that the application now alternates between the 'old' zoom factor
    and the new zoom factor.

I attach three low-quality videos taken with my digicam; please excuse the
interlacing artifacts. The first video shows the Hades simulation of the 
clock-generator demo without zoom operation or user interaction. This seems 
to work.

In the second video, I initiate a zoom-out operation. My app now only keeps
the zoom-out schematics, but this somehow gets overdrawn periodically by 
a backbuffer that still has the original zoom-factor.

The third video shows the situation after another zoom-out operation. The
schematics should become even smaller (and it does), but Swing somehow still
keeps the original image...



As my app does all drawing via its own backbuffer, which now has the new
zoom factor (otherwise the schematics would never be drawn with the new zoom),
this implies that SWING SOMEHOW KEEPS ITS OWN BACKBUFFER AND WRONGLY OVERWRITES
MY FigSwingCanvas.

A very similar thing happens in jfig, where panning on the main canvas works,
while zooming does not. The only difference is that panning is handled
internally by FigSwingCanvas, while zooming also later does a setText() call
on the JTextField used to display the new zoom factor. The repaint generated 
by the setText() call then immediately overwrites the correct new display
with some backbuffer contents managed by Swing. To prove this, I temporarily
removed the setText() call and jfig behaved as it should after zoom operations.

So: some redraw operations in free Swing use broken (too large) clip regions
and overwrite components with the Swing-manager back-buffer. This should never
happen as my component claims isDoubleBuffered=false and isOpaque=true.

Any ideas on how to further debug this are highly appreciated!


-- 
           Summary: Wrong clip region in Swing repaints - overwrites other
                    components
           Product: classpath
           Version: 0.92
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: swing
        AssignedTo: roman at kennke dot org
        ReportedBy: hendrich at informatik dot uni-hamburg dot de


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]