Open
Bug 602303
Opened 14 years ago
Updated 2 years ago
Linux needs a mechanism to dispatch starved paints
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
NEW
People
(Reporter: tnikkel, Unassigned)
References
Details
(Keywords: platform-parity)
Our win32 widget code has a mechanism to dispatch starved paints (see nsWindow::DispatchStarvedPaints). When bug 130078 landed is inadvertently disabled this code and that resulted in a few bugs on Windows (bug 601547, bug 592954, bug 592093 and maybe more). Linux has these same bugs, but they pre-exist bug 130078 because Linux does not seem to have any mechanism to dispatch starved paints. We should add such a mechanism on Linux so these bugs don't appear on Linux.
Comment 1•14 years ago
|
||
I was thinking about when we should process updates. There seem to be two situations where this would make sense: 1) When mouse motion events are getting compressed. 2) When keyboard autorepeat is throttled. Updates would be best dispatched after sending the event (to be as up-to-date as possible). For other keyboard and button events, if we are not keeping up, then it probably usually makes more sense to wait to paint a whole word rather than each character individually, or wait to find out if it is a double or triple click, etc. Maybe we could ensure to paint within 0.5 seconds after input or something, but I'm not so keen on forcing a paint after every input event. There are two other places where that are similar 1) repeated mouse scroll events. We should probably compress these too, but rather than throttle by throwing away events, we can probably merge by adding deltas or something. If we do that then we could probably force a paint after compression. 2) drag motion events. I'd have to check the spec to see whether these should be already throttled by responses from the prospective destination. Currently we generate extra unthrottled drag over events, but I'm hoping to remove this in bug 495343. If/Once these are throttled then we can force a paint, which could be useful for indicating drop-receptiveness.
Reporter | ||
Comment 2•13 years ago
|
||
In bug 627628 the code was changed to dispatch less starved paints overall.
Reporter | ||
Comment 3•13 years ago
|
||
On Windows.
Comment 4•5 years ago
|
||
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•