The future of MirInputEvent

Hi All, In case anyone has missed it there's a debate about future direction started on two competing MPs: https://code.launchpad.net/~alan-griffiths/mir/event-timestamps/+merge/262879 https://code.launchpad.n

Re: The future of MirInputEvent

Hi! I think the value of MirInputEvent is pretty limited. I think it's possible to defend as correct, for example something may wish to access the time of events without knowing the event type...even then though this seems pretty marginal. On the other hand there is no way to implement the convers

New Buffer Semantics Planning

I've started spiking a bit on how to transition the system to what we've been calling the new buffer semantics¹, and come up with a plan. We've already landed the ipc plumbing, now we have to make use of it to its potential. Obviously, the number one thing to avoid is regressions in performance or

Re: New Buffer Semantics Planning

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

Re: The future of MirInputEvent

+1 on having a discussion. I wondered the same when I touched those APIs a few months ago. I don't think the intermediate InputEvent is useful enough to keep. Conceivably any app/toolkit developer could want to correlate other types of events with input just as much as correlating input with i

Re: New Buffer Semantics Planning

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

Re: The future of MirInputEvent

On Fri, Jun 26, 2015 at 12:09 PM, Daniel van Vugt wrote: +1 on having a discussion. I wondered the same when I touched those APIs a few months ago. I don't think the intermediate InputEvent is useful enough to keep. Conceivably any app/toolkit developer could want to correlate other types of

Re: New Buffer Semantics Planning

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

Re: New Buffer Semantics Planning

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

Re: New Buffer Semantics Planning

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

Re: New Buffer Semantics Planning

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

Re: New Buffer Semantics Planning

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

Re: New Buffer Semantics Planning

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