Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for X Present extension #1769

Merged
merged 14 commits into from
Jun 19, 2024
Merged

Conversation

CendioOssman
Copy link
Member

This makes it possible for applications to synchronize their updates to the updates sent out to clients. This avoids tearing, and could in the future also help with rate limiting applications to what the client can actually show.

@CendioOssman CendioOssman added the enhancement New feature or request label Jun 19, 2024
Repeating a timer can be done in two ways:

 * Returning true from the handler
 * Calling start() again in the handler

The latter is useful if you want to change the timer interval.

If both are used, then it becomes ambiguous when the timer should fire
again.

Detect this case and warn about it. Current implementation will respect
the new interval given to start(), rather than the interval set before
running the handler.
This should have been done in a4308c9.
It is much more sane to treat "0" as "a timer is ready NOW", so let's
change to using -1 as the invalid timeout value.
It currently won't ever be called with an empty list of timers, but it
is a public function so that might happen in the future. Make sure this
case is handled without crashes.
They were badly formatted, way longer than the normal 72 columns.
One-shot timers are more common, so let's change the API a bit to make
that use case simpler. This API also makes it more clear what is
happening.
The desktop isn't completely paused just because there are no clients,
so it might still need some support from the server object.

This is primarily an issue for headless servers, where they need to
continue emulating things even without clients. A scraping server can
generally go completely passive if there are no clients.
Let's avoid requring these as a desktop implementation can now set up
everything in the init() method.
This makes it possible for applications to synchronize their updates to
the updates sent out to clients. This avoids tearing, and could in the
future also help with rate limiting applications to what the client can
actually show.
This marks the timer as started again, before we call out to various
external places that might be confused by the frame timer reporting that
it is stopped.
If there is something interested in synchronizing to a frame tick, then
keep the frame clock running, even if there are no updates.

This is need mainly when something starts rendering, but also when
something renders much slower than the frame clock (so it is essentially
constantly "starting"). Such an application will not draw anything until
it gets a new frame tick, which it won't get as the frame clock is
waiting for something to start drawing.
Run the frame clock at a slow 1 Hz if there are no clients connected.
This is similar to what a normal X server does when the screen is
blanked, and should keep applications waiting for the frame tick happy.

Note that we still only keep the frame clock running if there is any
application that are interested in it. Otherwise we still stop it
completely.
@CendioOssman CendioOssman merged commit 858a859 into TigerVNC:master Jun 19, 2024
12 checks passed
@CendioOssman CendioOssman deleted the present branch June 19, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant