Some further planning notes (also a repeat of what I chatted about in the
us/euro standup about https://trello.com/c/I8s7W2f9)
I proposed these 3 branches today:
https://code.launchpad.net/~kdub/mir/multimonitor-arbiter/+merge/265301
https://code.launchpad.net/~kdub/mir/dropping-schedule/+merge/26
So, as far as planning goes
I think that the spreadsheet (with a few nuances, perhaps) plus the
BufferQueue.* tests give us a good capture of the requirements.
So, seems sensible to link the translation of the BufferQueue tests and the
capture of the requirements into the new integration-leve
TL;DR email is messy
See this instead:
https://docs.google.com/spreadsheets/d/1qf3IssN_sujygMPK2sTX2AUhGiDUBF3TMYYcSRSaSy0/pubhtml
On 26/06/15 12:24, Daniel van Vugt wrote:
That's why it's a hard problem to replace BufferQueue -- you have to
figure out whether 2, 3 or 4 buffers for any given
On Fri, Jun 26, 2015 at 2:24 PM, Daniel van Vugt
wrote:
That's why it's a hard problem to replace BufferQueue -- you have to
figure out whether 2, 3 or 4 buffers for any given surface is correct
at the time. Never over-allocate and never under-allocate (which
causes freezing/deadlocks).
What
That's why it's a hard problem to replace BufferQueue -- you have to
figure out whether 2, 3 or 4 buffers for any given surface is correct at
the time. Never over-allocate and never under-allocate (which causes
freezing/deadlocks).
What I was suggesting is that a frame callback (for non-idle s
On Fri, Jun 26, 2015 at 2:04 PM, Daniel van Vugt
wrote:
Hmm, maybe not. If we assume the server is only communicating with the
client at 60Hz then the client could just do all the dropping itself
and
send one frame (the newest completed one) every 16.6ms when the
server asks.
I don't thin
Hmm, maybe not. If we assume the server is only communicating with the
client at 60Hz then the client could just do all the dropping itself and
send one frame (the newest completed one) every 16.6ms when the server asks.
On 26/06/15 12:01, Daniel van Vugt wrote:
bypass/overlays: If you look a
bypass/overlays: If you look at the current logic you will see that the
DisplayBuffer holds the previous bypass/overlay buffer until _after_ the
client has provided the next one. And it must, to avoid scan-out
artefacts. So the server holds two of them very briefly. But only one is
held most of
On Fri, Jun 26, 2015 at 12:39 PM, Daniel van Vugt
wrote:
I'm curious (but not yet concerned) about how the new plan will deal
with the transitions we have between 2-3-4 buffers which is neatly
self-contained in the single BufferQueue class right now. Although as
some responsibilities clearly l
I'm curious (but not yet concerned) about how the new plan will deal
with the transitions we have between 2-3-4 buffers which is neatly
self-contained in the single BufferQueue class right now. Although as
some responsibilities clearly live on one side and not the other, maybe
things could beco
Sounds good.
+1 on the new-buffer-semantics switch as I'm a bit worried about regressing
on some of the lag & latency reduction work that went in.
Thanks
On Thu, Jun 25, 2015 at 1:51 PM, Kevin DuBois
wrote:
> I've started spiking a bit on how to transition the system to what we've
> been calli
11 matches
Mail list logo
