Dirty Rectangles and optimized scrolling

[aleitner]

We are developing an application that is using CEF to render the contents of a web page remotely. As such, we are interested in ensuring that changes to the browser display are as efficient as possible in terms of the size of the region(s) of the display updated during any particular frame.

Is there a mechanism available for CEF to give us true dirty rectangles for individual display changes?
The callbacks provided by CEF account for the possibility of multiple dirty rectangles, but in practice actually only ever provide a single dirty rectangle covering all changes since last frame. For example, if there animations at the top and bottom of a page, we will get a dirty rectangle covering the entire page, even though the majority of that rectangle has not changed and two rectangles would be more efficient.

Is there a mechanism available within CEF for optimized rendering of scrolling?
There does appear to be a scroll callback that may be usable, but that scroll callback receives non-integer scrolling deltas. If there were a way to force CEF to clamp its scrolling to integer, whole-pixel values, we would be able to represent those scrolling events more efficiently without redrawing portions of the scrolled region that have not truly changed.

[magreenblatt]

I believe both of the features that you’re requesting would require changes in Chromium.

[aleitner]

Ahh that's too bad, but thanks for always responding so quickly! I do have a few other general questions. Should I continue posting them in this thread or make new threads for each of them?

[magreenblatt]

You can continue posting here, thanks.

[aleitner]

The text cursor displayed within input fields does not always render when a text box is focused. Is this something we're doing wrong? Or perhaps a known issue?
We are seeing this behavior only on pages with highly customized input fields, like the search boxes of Youtube or Google. On pages with standard text input fields, the text cursor appears normally.

Is there a mechanism available within CEF to communicate the DPI or pixel ratio that should be used for rendering?
There are definitely methods available to inform CEF of a change to the available display space, but there does not appear to be any method to additionally inform CEF of the DPI applicable to that space (pixel ratio).

Is there a mechanism available within CEF that would allow us to always receive updated mouse cursor images for cursor changes?
There is a mechanism available for obtaining the mouse cursor image following an update to the cursor, but that mouse cursor appears to be omitted when CEF is operating on a headless server, and we instead have to fall back on our own bundled copies of possible cursors.

Is it possible to leverage CEF without the portion of the application leveraging CEF needing an entirely separate and dedicated binary that executes itself?
CEF appears to depend on executing itself repeatedly as a means of achieving process isolation. This makes communication between processes a bit awkward, as we have to rely on mechanisms like shared memory combined with options passed on the command-line. If it were possible to use fork() such that the child CEF process(es) can pull everything they need from the memory they inherit from the parent process, that would be awfully convenient.

[magreenblatt]

The text cursor displayed within input fields does not always render when a text box is focused.

This sounds like a bug.

Is there a mechanism available within CEF to communicate the DPI or pixel ratio that should be used for rendering?

Are you using CefRenderHandler::GetScreenInfo to set device_scale_factor?

mouse cursor appears to be omitted when CEF is operating on a headless server

That could be a bug, or a limitation of running in a headless environment.

Is it possible to leverage CEF without the portion of the application leveraging CEF needing an entirely separate and dedicated binary that executes itself?

Subprocesses can use the same binary or a separate binary. Implementation details (of fork()ing, etc) are up to Chromium.

[magreenblatt]

This makes communication between processes a bit awkward, as we have to rely on mechanisms like shared memory combined with options passed on the command-line.

There are other options, see https://bitbucket.org/chromiumembedded/ ... cation-ipc. We also recently added efficient binary transfer in https://github.com/chromiumembedded/cef/issues/3502

[aleitner]

Thank you for your answers. Initially, I had initialized the CEF app within my main application, but it seemed to cause multiple processes running under my application binary. To avoid this, I created a separate binary for CEF initialization and handling logic. This separate binary is executed by my main application and they communicate via shared memory, mainly for passing the rendered screen data from CEF process to the main application.

However, from your response, it seems that initializing the CEF app within the main application process is also a possibility and the bifurcation into separate binaries might not necessarily be essential. I guess I will need to look more into the details of Chromium's handling of such processes. Do you have any links that go into detail about how I can set this up?

[magreenblatt]

See https://bitbucket.org/chromiumembedded/ ... -processes