Closed Bug 65996 Opened 24 years ago Closed 23 years ago

setting innerHTML flickers

Categories

(Core :: Layout, defect)

x86
Windows 98
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: wo, Assigned: kmcclusk)

Details

(Keywords: testcase)

Attachments

(1 file)

Repeatedly setting the innerHTML value of an element produces a rather disturbing flicker. testcase: <div id="test" style="width:500px"> </test> <script> onload=tick; function tick(){ for (var str="", i=200; i--; ) str+="0 "; str+=new Date().getTime(); document.getElementById("test").innerHTML=str; setTimeout("tick()",50); } </script> With M0.7/win98 this doesn't look nice. Compare how IE5 displays it. (Note that overwriting layer contents to produce the same effect in NN4 also works without visible flicker.) I know that innerHTML isn't in the W3C standard, but certainly innerHTML is and will be used excessively for dynamic webpages.
Attached file the testcase (deleted) —
Microsoft checks the current content, and only change the part that has been changed after the last call. You might do that yourself, 50 times faster then the current result!
Confirmed Platform: PC OS: Windows 98 Mozilla Build: 2001011904 Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
I was wrong informed about that MSIE innerHTML stuff. I run some tests and now I know that MSIE is not updating the new content only, but in fact the whole str as it has to do. It seems just lack of javascript performanche what causes this bug report.
Has this improved in today's build? I think kmcclusk checked in some changes relating to the scheduling of painting for bug 36849.
no, the same amount of flicker with build 2001012020.
kmcclusk, jst: who should get this bug?
taking the bug.
Assignee: clayton → kmcclusk
Status: NEW → ASSIGNED
Setting milestone to Mozilla1.0
Target Milestone: --- → mozilla1.0
Clearing milestone.
Target Milestone: mozilla1.0 → ---
It looks like invalidates are being called from several places. from the block code when a textframe is destroyed. from the style system when an attribute is changed. from the timer callback when content is added. The flicker is probably the result of these invalidates happening indepedently so their are PAINT messages in the message queue which are being processed inbetween some of invalidate calls.
Target Milestone: --- → Future
on build 2001102903 win32 this wfm
indeed, looks very fine on 2001-10-31/win98 as well.
This problem disappeared half a year ago and hasn't reappeared since, so I'm marking it as FIXED now. Hope that's okay.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: