Hi,
On 17 February 2017 at 14:22, Pekka Paalanen wrote:
> On Thu, 16 Feb 2017 14:53:39 +
> Daniel Stone wrote:
>> I was about to say 'this doesn't gain us anything', except if all
>> clients do submit and trigger repaint immediately, there's a 7ms grace
>> period where we could potentially g
On Thu, 16 Feb 2017 14:53:39 +
Daniel Stone wrote:
> Hi,
>
> On 16 February 2017 at 14:31, Pekka Paalanen wrote:
> > On Tue, 14 Feb 2017 13:18:05 +
> > Daniel Stone wrote:
> >> On startup, we cannot lock on to the repaint timer because it is unknown
> >> to us. We deal with this by c
Hi,
On 16 February 2017 at 14:31, Pekka Paalanen wrote:
> On Tue, 14 Feb 2017 13:18:05 +
> Daniel Stone wrote:
>> On startup, we cannot lock on to the repaint timer because it is unknown
>> to us. We deal with this by claiming that the moment of entry into the
>> repaint loop is the moment a
On Tue, 14 Feb 2017 13:18:05 +
Daniel Stone wrote:
> On startup, we cannot lock on to the repaint timer because it is unknown
> to us. We deal with this by claiming that the moment of entry into the
> repaint loop is the moment a frame returned, causing finish_frame to
> delay our initial rep
On startup, we cannot lock on to the repaint timer because it is unknown
to us. We deal with this by claiming that the moment of entry into the
repaint loop is the moment a frame returned, causing finish_frame to
delay our initial repaint to (refresh_time - repaint_delay), typically
around 9ms of u
