Bug 29865 - wrong clip in JScrollpane repainting
Summary: wrong clip in JScrollpane repainting
Status: UNCONFIRMED
Alias: None
Product: classpath
Classification: Unclassified
Component: swing (show other bugs)
Version: 0.93
: P3 normal
Target Milestone: ---
Assignee: Roman Kennke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-16 08:36 UTC by Norman Hendrich
Modified: 2006-11-16 08:37 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
screenshot showing the repaint issue (128.88 KB, image/gif)
2006-11-16 08:37 UTC, Norman Hendrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norman Hendrich 2006-11-16 08:36:13 UTC
One of the recent RepaintManager/repaint updates breaks JScrollPane 
in my image-viewer application [1]. See attached image for an example.
A cvs checkout from 2006.11.06 worked fine, while checkouts from
2006.11.13 and 2006.11.16 both show the same problem.

Note that JScrollPane seems to work fine with most "standard" clients
like JTree. It also works fine with my ImageViewer whenever a full
repaint is performed (like un-obscuring the scrollpane, changing the
size, etc.).

The bug only occurs after typing the "cursor down" key, which is
handled twice: it tells Niffler to load and display the next image,
but it is also intercepted by the JScrollPane which scrolls up one
line-increment. As you can see, the new image is loaded and mostly
painted, but one line-increment-part of the old image is blitted
into it. This can be repeated for some fun.

To reproduce the bug, you need images that are larger than the
scrollpane size and to disable the zoom-to-fit option (menu->
view->zoom fit after loading), in order to make the scrollbars
appear.



[1] tams-www.informatik.uni-hamburg.de/people/alumni/hendrich/niffler
Comment 1 Norman Hendrich 2006-11-16 08:37:29 UTC
Created attachment 12629 [details]
screenshot showing the repaint issue