1,295
edits
| Line 60: | Line 60: | ||
=== Interaction With OS Painting === | === Interaction With OS Painting === | ||
I expect that the window update will be performed via an XPCOM event. The last step will be platform-specific; some platforms might need to stash the buffer somewhere, force a synchronous platform-level paint, and draw out of the buffer in an event handler. | I expect that the window update will be performed via an XPCOM timer event. The last step will be platform-specific; some platforms might need to stash the buffer somewhere, force a synchronous platform-level paint, and draw out of the buffer in an event handler. | ||
When a platform expose event is received, we add the dirty area to our invalid region and handle it as an immediate window update. This events will be increasingly rare as platforms move to compositing window managers. This approach may cause problems if the platform handles scrolling and widget movement badly during an expose event; if so, then an unanticipated platform expose event with plugin movement or scrolling pending will need to be handled by just adding the exposed area to the invalid region and calling | When a platform expose event is received, we add the dirty area to our invalid region and handle it as an immediate window update. This events will be increasingly rare as platforms move to compositing window managers. This approach may cause problems if the platform handles scrolling and widget movement badly during an expose event; if so, then an unanticipated platform expose event with plugin movement or scrolling pending will need to be handled by just adding the exposed area to the invalid region and calling RequestUrgentUpdate() to schedule a window update. | ||
=== Prioritization === | === Prioritization === | ||
edits