Windows message loop being hogged by CEF with autoplaying looped corrupted mp4 file.

Issue #3343 resolved
Nicholas Chapman created an issue

To replicate:

Use off screen rendering with CEF on Windows. I am using Branch 4951 currently.

Load the following html file: test.html, which references a corrupted (probably truncated) mp4 file.

Then hold left mouse button and move the mouse pointer rapidly in the host app (a realtime opengl app).

Result: no camera movement in the host app takes place (it usually would due to mouse movement)

Breaking in the debugger while the app is hitched gives this call stack:

    win32u.dll!NtUserGetQueueStatus?()  Unknown
>   libcef.dll!base::MessagePumpForUI::ProcessNextWindowsMessage() Line 479 C++
    libcef.dll!base::MessagePumpForUI::DoRunLoop() Line 210 C++
    libcef.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 80    C++
    libcef.dll!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool application_tasks_allowed, base::TimeDelta timeout) Line 500 C++
    libcef.dll!base::RunLoop::Run(const base::Location & location) Line 143 C++
    libcef.dll!base::RunLoop::RunUntilIdle() Line 152   C++
    libcef.dll!CefDoMessageLoopWork() Line 255  C++
    gui_client.exe!CefDoMessageLoopWork() Line 125  C++
    gui_client.exe!CEF::doMessageLoopWork() Line 164    C++
    gui_client.exe!MainWindow::timerEvent(QTimerEvent * event) Line 2865    C++

As far as I can tell the CEF message loop somehow seems to be consuming all my mouse move events, or something similar is happening.

I made a video demonstration of the issue:

The first 15 seconds shows normal camera movement with keyboard keys. After that I try and move the camera with the mouse, and as long as the frequency of mouse events is sufficiently high, CEF seems to consume them all, and no camera movement takes place.

EDIT: some more ‘interesting' details:

Removing the ‘loop’ attribute from the html video element almost completely eliminates the issue.

Playing a non-corrupted mp4 file greatly reduces the issue, although there is some remaining stuttering.

EDIT 2: Host app uses Qt.

Possibly this particular page loaded by CEF severely exacerbates an existing issue with the qt event handling system.

Comments (3)

  1. Nicholas Chapman reporter

    After further investigation, the issue was with the dropbox shell extension on my computer making peekmessage very slow, so not CEF's fault.

  2. Log in to comment