With these flags API consumers can optimize the depiction of libliftoff's debug
log.
For now the two flags for a section start and end are introduced. It is
guaranteed that one section always ends before the next one begins.
Is no callback function setup section starts and ends in the default stderr
output will be marked with an empty line.
BREAKING CHANGE: The signature of the log callback changes.
Instead of exposing to consumers write streaming log data into a per-device
buffer that gets created on request and destroyed after the buffer has been
written to the log.
Passing a NULL string to the internal continuous log function triggers a write
of the buffer to the log.
BREAKING CHANGE: continuous log function is moved from log header to private
header.
On apply to an output planes associated with the output are being reset. For
easier debugging make clear in the list in the log which planes have which
type.
Enumerating all planes to be disabled makes the log unnecessary
sparse. Instead just list all planes in a single line.
For that introduce new API function to log something without line
break in the end and adapt the log callback function pointer.
BREAKING CHANGE: log callback function arguments change.
On debug verbosity logging every reuse of planes is spamming the log making it
difficult to debug the process.
With this patch only the change of reusing the same allocation is logged and
how often the allocation was reused after this changed back again.
Compositors need to drive multiple connectors, each with its own vblank timings.
For each device, there's one separate rendering loop per output.
It's not possible to call liftoff_device_apply each time we want to submit a new
frame to one output, because this could touch another's output state, submitting
a new frame there in the process. When the other output will submit a new frame,
it'll get EBUSY (can't submit two frames without waiting for vblank).
Closes: https://github.com/emersion/libliftoff/issues/21
Start from scratch since we may be able to come up with a better allocation
(if the layer made another layer fall back to composition for instance).
Closes: https://github.com/emersion/libliftoff/issues/30
Keep track of the number of layer updates per 60 page-flips.
We could implement a more fine-grained tracking, for instance with a sliding
window. However it's a lot more complex than the current solution and the gains
are not clear. I'd prefer to keep the current solution and experiment with other
solutions once we have a good test-bed.
References: https://github.com/emersion/libliftoff/issues/22