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

Control batch delay for video regions #1130

Closed
totaam opened this issue Feb 19, 2016 · 9 comments
Closed

Control batch delay for video regions #1130

totaam opened this issue Feb 19, 2016 · 9 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Feb 19, 2016

Issue migrated from trac ticket # 1130

component: server | priority: major | resolution: wontfix

2016-02-19 00:22:02: sbennett created the issue


Similar to #1077 (manually control batch delay at runtime) this would allow for the batch delay for video regions to be set independently of non-video regions

@totaam
Copy link
Collaborator Author

totaam commented Feb 22, 2016

2016-02-22 16:26:38: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Feb 22, 2016

2016-02-22 16:26:38: antoine commented


The main batch delay drives everything, starting with the timers, and so adding a separate delay would conflict with that: we would have two timers firing independently... but they also need to cooperate as we send screen updates bundled up together as much as we can, even with video regions.

Unless we make this new video region batch delay a multiple of the other one, then a lot of the code would need to be duplicated. And even then, the "main" batch delay is adjusted automatically.. so we can't guarantee that a multiple would give us a fixed value either.

Changing the video refresh rate would also affect the main batch delay.

Then there's also the issue that we may want the video (or client vrefresh rate, or a combination of the two) to drive the video refresh rate to be able to handle the optimal framerate and not miss any frames (vsync and not tearing).

Finally, since this request is driven by client decode speed constraints, the adjustments should be automatic: the client already tells the server how long it takes to decode each frame and this should be the value we use to calculate the video batch delay.

@totaam
Copy link
Collaborator Author

totaam commented Feb 24, 2016

2016-02-24 09:56:26: antoine commented


See also: #1135.

@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2016

2016-08-10 03:42:58: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2016

2016-08-10 03:42:58: antoine changed owner from antoine to sbennett

@totaam
Copy link
Collaborator Author

totaam commented Aug 10, 2016

2016-08-10 03:42:58: antoine commented


I think there are too many conflicts with other features: #1257, #981, etc.

Maybe we can think of another way to achieve the same results? (new ticket)

@totaam
Copy link
Collaborator Author

totaam commented Sep 27, 2016

2016-09-27 10:50:52: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Sep 27, 2016

2016-09-27 10:50:52: antoine set resolution to wontfix

@totaam
Copy link
Collaborator Author

totaam commented Sep 27, 2016

2016-09-27 10:50:52: antoine commented


Things have changed quite a bit since this ticket was created (in particular #800 and #1135), let's create a new ticket with new requirements when we have them,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant