Closed Bug 3853 Opened 26 years ago Closed 26 years ago

[BLOCK] Title button widget causes infinite redraw

Categories

(Core :: XUL, defect, P1)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: eric)

References

()

Details

Start apprunner. Go to any page (I suggest the very minimal http://www.shallowsky.com/small.html as a test page). As soon as the page loads, apprunner goes into an infinite redraw loop -- you can see the vertical scrollbar and the rest of the chrome flickering.
Priority: P3 → P1
Target Milestone: M3
Im affraid im seeing the same thing in win32. Except rendering in win32 is much more effecient, os its harder to see the flickering. Try putting a printf in nsWindow::Invalidate() and notice how its always being called. Adding michaelp to cc.
OS: Linux → All
Hardware: PC → All
Summary: [PP BLOCK] Linux infinite redraw loop → [BLOCK] infinite redraw loop
Ramiro says this happens on win32 as well (but it's not as obvious because drawing is so much better optimized on win32). Removing PP designation.
Macos does this too. I just tried it.
what seems to be happening is that an invalidate is done to something at the upper right corner of the window. the imagelib is updating the bits of an animated gif *twice* with slightly different rects each time. these invalidates are sent off to the widget library to request that the updated area be repainted. when the paint request comes back under *windows* the damage repair rect is almost identical to the original damage requests and only one paint occurs because the damage requests are coalesced by windows. sooo, under windows we are continually painting what appears to be the throbber as the result of requests from the imagelib (in fact joki and i commented out the throbber from the xul yesterday and this went away). if other platforms are NS_PAINTing more than the damage repair request area, then that is bustage in the platform specific widget kits. why this is continually being damaged (and twice at that) by the image lib is a good question, but not really the big nut here.
QA Contact: 3853 → 3849
Setting QA Contact
What I'm seeing on Mac is this: whenever the status text changes (nsWebShell::OnStatus() is called), the attribute change is causing the entire content to be reflowed, which invalidates and redraws the entire window. This also explains why animated GIFs cause constant redraw (bug 3761) -- they cause the status message to keep changing.
I think pnunn fixed the "double imagelib updating" this afternoon. don, tell me about throbber changes in the last 2 days...
Commenting out the "observes throbber" line 533 of navigator.xul makes the problem go away (but also stops the throbber from animating).
Assignee: mcafee → don
Summary: [BLOCK] infinite redraw loop → [BLOCK]Throbber causes infinite redraw loop
Throbber. Don.
Assignee: don → law
Summary: [BLOCK]Throbber causes infinite redraw loop → [BLOCK] Layout/progress meter causes infinite redraw
Re-assigned to law@netscape.com and changed summary and component to XPApps. Bill has a workaround/fix for this now ...
*** Bug 3885 has been marked as a duplicate of this bug. ***
Assignee: law → evaughan
Component: Apprunner → XP Toolkit/Widgets
Summary: [BLOCK] Layout/progress meter causes infinite redraw → [BLOCK] Title button widget causes infinite redraw
Re-assigned to evaughan@netscape.com and changed summary and component to XP Toolkit/Widgets. Bill's fix is not enough. The real culprit is the title button widget. :-)
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Resolved as FIXED.
Could someone explain what the fix was for this? It's scarey when some pointy- head just closes the bug, with no explanation of what the fix was ;-) Specifically, I'd like to see a comment on whether the same fix is expected to solve 3761 as well (and that problem still exists in today's build).
*** Bug 3877 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
using the 2nd build from 3/17, checking on all platforms, the infinite redraw has stopped.
You need to log in before you can comment on or make changes to this bug.