Bug 1674982 [Wayland] Revert frame callbacks timeout due to OOM crashes, r=jhorak

Wayland protocol does not include a mechanism how to inform compositor about deleted frame callbacks.
We delete a callback only locally on client side and it remains active at server (compositor) side.

When large amount of callbacks is accumulated at server Firefox is closed due to OOM
so we need to keep frame callback on local side untill is fired and don't create a new one.

Differential Revision: https://phabricator.services.mozilla.com/D95678
This commit is contained in:
stransky 2020-11-03 09:53:51 +00:00
Родитель ea5444d838
Коммит 3081c62a8e
1 изменённых файлов: 2 добавлений и 9 удалений

Просмотреть файл

@ -37,9 +37,6 @@ extern mozilla::LazyLogModule gWidgetWaylandLog;
// Maximal compositing timeout it miliseconds
#define COMPOSITING_TIMEOUT 200
// Maximal timeout between frame callbacks
#define FRAME_CALLBACK_TIMEOUT 20
namespace mozilla {
namespace widget {
@ -1002,12 +999,8 @@ void WindowSurfaceWayland::CommitWaylandBuffer() {
if (waylandSurface == mLastCommittedSurface) {
LOGWAYLAND((" [%p] wait for frame callback.\n", (void*)this));
// We have an active frame callback pending from our recent surface.
// It means we should defer the commit to FrameCallbackHandler(),
// but only if we're under frame callback timeout range.
if (mLastCommitTime && (g_get_monotonic_time() / 1000) - mLastCommitTime <
FRAME_CALLBACK_TIMEOUT) {
return;
}
// It means we should defer the commit to FrameCallbackHandler().
return;
}
// If our stored wl_surface does not match the actual one it means the frame
// callback is no longer active and we should release it.