Closed Bug 288222 Opened 15 years ago Closed 15 years ago

Widget reconfiguration doesn't always happen in a timely manner

Categories

(Core :: Web Painting, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: roc, Assigned: roc)

References

Details

Attachments

(1 file)

While debugging my new scrollframe patch I noticed that during rapid resizing I
was sometimes drawing garbage for a moment. What's happening is that during the
resize reflow of the content area, we resize the scrolling view. Its widget
resize is deferred because of the batch around the reflow. After the reflow we
enable refresh, but we defer processing of pending updates. Before that event
happens, we get an expose event, I presume from the window system because the
widgets in the chrome have resized. We repaint poorly because the widget is not
in sync with its view.

I have a patch that fixes this by running ProcessPendingUpdates inside
Refresh(), but not triggering the pending paints, just reconfiguring widgets. (I
presume based on Boris' comments there that triggering invalidates would cause
problems.) I'm not 100% sure this is the best way to fix the issue...
Attached patch fixSplinter Review
Attachment #178996 - Flags: superreview?(bzbarsky)
Attachment #178996 - Flags: review?(bzbarsky)
Comment on attachment 178996 [details] [diff] [review]
fix

r+sr=bzbarsky, but I think aDoInvalidate may be better than aDoPaint... We
aren't really painting, just telling the widget the area needs to be painted.
Attachment #178996 - Flags: superreview?(bzbarsky)
Attachment #178996 - Flags: superreview+
Attachment #178996 - Flags: review?(bzbarsky)
Attachment #178996 - Flags: review+
I checked this in.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Is this related to bug 268320?
It certainly could be.
Blocks: 274637
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.