Closed Bug 912352 Opened 7 years ago Closed 6 years ago

Windows OMTC window resizing - part two

Categories

(Core :: Graphics: Layers, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla26

People

(Reporter: nrc, Assigned: nrc)

Details

Attachments

(1 file)

Following up bug 899435. Those fixes seem necessary but not sufficient - they make things better but not perfect. In particular, resizing with the top or left sides is still not smooth.
The problem is that when we resize, Windows does not repaint the window at the new location (when resize from the top or left we are kind of moving the window as well as resizing it). So either the window has a big white patch or it is inappropriately clipped.

The reason seems to be that when we resize we reflow then invalidate the window with Windows which gets us a WM_PAINT and then we repaint the entire window and then do a transaction causing us to composite. And while that happens, we just have the old pixels on screen. The solution (I think) is to do an async composite as soon as we get the WM_PAINT message then start repainting.

New texture space is black rather white too. We should probably change that.
Attachment #799296 - Flags: review?(roc)
Comment on attachment 799296 [details] [diff] [review]
composite asap on WM_PAINT

Review of attachment 799296 [details] [diff] [review]:
-----------------------------------------------------------------

nice
Attachment #799296 - Flags: review?(roc) → review+
https://hg.mozilla.org/mozilla-central/rev/feb179160273
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.