On 2020-06-24 5:19 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> I assume 2. refers to the case of a single late frame, where the
>> next frame hitting the original absolute target would result in a
>> second visible stutter. While writing
>>
Michel Dänzer writes:
> I assume 2. refers to the case of a single late frame, where the next
> frame hitting the original absolute target would result in a second
> visible stutter. While writing
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234
> , it occurred
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different
> way of doing frame timing.
>
> Instead of specifying *when* a particular frame should be
> displayed, how about we specify how *long* a particular frame
> should be made visible
Michel Dänzer writes:
> Should this extension specify how it interacts with the various
> VK_PRESENT_MODE_* modes?
Yes. It needs to be clear on how this extension interacts with all
existing display stuff. Thanks for pointing out one pretty important
interaction.
> For one example: With
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different
> way of doing frame timing.
>
> Instead of specifying *when* a particular frame should be
> displayed, how about we specify how
Michel Dänzer writes:
> I think at least the following needs to happen first:
>
> * At least a prototype of plumbing through this information to the
> amdgpu kernel driver (or another one which may grow VRR support) and
> making use of it for adjusting the refresh periods to allow hitting
> the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-07 10:19 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> With variable refresh rate, it could certainly be useful for the
>> kernel to have this information as early as possible. It
>> shouldn't make any difference with fixed
Michel Dänzer writes:
> With variable refresh rate, it could certainly be useful for the kernel
> to have this information as early as possible. It shouldn't make any
> difference with fixed refresh though, since the kernel should always be
> able to hit the next refresh in that case as long as
On 2020-02-04 8:12 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> Hmm, I didn't fully realize this in my reading of the draft, thanks
>> Matias for pointing it out!
>>
>> That the timing of frame N+1 has to be specified when submitting frame
>> N for presentation is odd to me TBH. While
Michel Dänzer writes:
>> actual_period = n * r - ε
>
> Is that still an issue if the (minimal) length of a vertical blanking
> period is subtracted from the computed period?
What you're doing is defining a 'window' of times which match the
desired frame -- any time within 'length of vertical
Michel Dänzer writes:
> Hmm, I didn't fully realize this in my reading of the draft, thanks
> Matias for pointing it out!
>
> That the timing of frame N+1 has to be specified when submitting frame
> N for presentation is odd to me TBH. While I can imagine this might be
> suitable for some apps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-03 8:48 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> Instead of rounding to the nearest upcoming frame, should it
>> round to the earliest frame after the specified period has
>> passed? As written, it seems to contradict the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-03 9:16 p.m., Keith Packard wrote:
> "Matias N. Goldberg" writes:
>
>> I read your article.
>
> Thanks!
>
>> What I feel are missing are just minor pesky details:
>
> Yes, it's definitely a rough draft at best. Figuring out the right
>
"Matias N. Goldberg" writes:
> I read your article.
Thanks!
> What I feel are missing are just minor pesky details:
Yes, it's definitely a rough draft at best. Figuring out the right words
to make it do precisely what we want is hard, and I'm hoping we can
first figure out what we want, then
Michel Dänzer writes:
> Instead of rounding to the nearest upcoming frame, should it round to
> the earliest frame after the specified period has passed? As written, it
> seems to contradict the next paragraph below:
Sorry for the poor wording; let me describe what I want informally here.
For
Hi!
I read your article.
What I feel are missing are just minor pesky details:
1. Written as is, the frame being submitted is rounded up to display timing,
delaying *future* frames.But there is no way to delay the *currently displaying
frame* (i.e. the 'previous' frame).
Right now if frame N
On 2020-02-02 7:51 a.m., Keith Packard wrote:
>
> I spent some time over the last week experimenting with a different way
> of doing frame timing.
>
> Instead of specifying *when* a particular frame should be displayed, how
> about we specify how *long* a particular frame should be made visible
I spent some time over the last week experimenting with a different way
of doing frame timing.
Instead of specifying *when* a particular frame should be displayed, how
about we specify how *long* a particular frame should be made visible
to the user?
This has a couple of advantages over the
18 matches
Mail list logo
