Closed Bug 288222 Opened 15 years ago Closed 15 years ago
Widget reconfiguration doesn't always happen in a timely manner
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...
15 years ago
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.
I checked this in.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Is this related to bug 268320?
It certainly could be.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.