Closed
Bug 29118
Opened 25 years ago
Closed 24 years ago
Tiled animated GIFs refresh the wrong area
Categories
(Core :: Web Painting, defect, P3)
Core
Web Painting
Tracking
()
VERIFIED
FIXED
M17
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.
Comment 1•25 years ago
|
||
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
Comment 3•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M17
Reporter | ||
Comment 4•25 years ago
|
||
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
Reporter | ||
Comment 5•25 years ago
|
||
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.
Assignee | ||
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
I'm not able to reproduce this problem with the June 1 Mac build. Marking
verified fixed.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 8•24 years ago
|
||
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.
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•