Closed Bug 29118 Opened 25 years ago Closed 24 years ago

Tiled animated GIFs refresh the wrong area

Categories

(Core :: Web Painting, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: kmcclusk)

Details

When loading a page (with double-buffering turned off in the view manager) I notice that the Netscape icon (the half ship wheel) in the taskbar flickers like crazy as the progress bar is being redrawn. We seem to be invalidating or redrawing too much at some point. The progress bar also draws very erratically, and does not smoothly progress as it should.
Progess meter is implemented with a animated background image and a style rule to turn it on or off. Invalidating and redraws are all done by Gecko.
Assignee: evaughan → troy
Component: XP Toolkit/Widgets: XUL → Layout
QA Contact: paulmac → petersen
This is not a layout bug. Changing component to Style System
Assignee: troy → pierre
Component: Layout → Style System
QA Contact: petersen → chrisd
What I'm seeing is slightly different from what Simon reported. If you don't hide the sidebar, you can see that it's not the Netscape icon that flashes but a 32x32 square below the progress bar. To reproduce, I recommend to turn on Paint Flashing in the Debug preferences instead of turning off the double-buffering, and connect to http://asd.zxc.ru (it always takes a while for the Russians to figure out that the machine doesn't exist so it puts the progress bar on for a spin). You can see that extra paintings happen both near the progress bar and the throbber. It seems to me that the spurious paintings have the same size as the last area that was legitimately painted. It is as if we were painting near the progress bar something that has the same size as the throbber icon, and near the throbber something that has the same size (or at least the same width) as the progress bar. It looks like a problem with the View Manager. I had the same results on Mac and Windows, with and without ViewManager2. Changed platform to All and reassigned to Views.
Assignee: pierre → kmcclusk
Component: Style System → Views
OS: Mac System 8.5 → All
QA Contact: chrisd → petersen
Hardware: Macintosh → All
Status: NEW → ASSIGNED
Target Milestone: M17
What's happening here seems to be a general bug with the updating of animated GIFs which are tiled (or maybe scaled too). imglib sends a notification, via the observer mechanism, that the GIF has been updated, and needs repainting. The bug is that nsFrameImageLoader uses the dimensions of the GIF, not the frame containing the GIF, when invalidating the area that needs to be redrawn. Since the progress meter is a 32x32 GIF, we end up invalidating an area below the progress bar. Adjusting summary.
Summary: Extra refreshes while drawing the progress bar → Tiled animated GIFs refresh the wrong area
The code in the nsImageNotification_kPixmapUpdate case of nsFrameImageLoader::Notify() does the wrong thing also when the GIF is smaller than its containing frame (e.g. the throbber). This code breaks if the GIF is not top-left in the frame. Things seem better if you simply call DamageRepairFrames(nsnull); in this case too.
Mark Attinasi checked in changes to nsFrameImageLoader to invalidate only the dimensions of the frame rather than the dimensions of the image. Following Pierre's directions, I don't see it drawing beyond the bounds of the throbber and progress bar. Marking Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I'm not able to reproduce this problem with the June 1 Mac build. Marking verified fixed.
Status: RESOLVED → VERIFIED
I still see updates for the progress bar in mozilla leak outside of the progress bar area -- it hits 2-3 pixels below the bar. Not sure if that's this bug, or a view thing.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.