WIP: towards more optimal rendering in cOPs

[jcorbin]

A PoC that doesn't yet actually work; but you know what's better than two display buffers? Just One.

It can be more optimal for sparse updates since it will (and can potentially do better) by moving diagonally between chunks.

Plus it introduces something to own the write/byte buffer between rounds.

[kriskowal]

This kind of experimentation is why I love reinventing the wheel. Between my discovery that using "\r" is more suited than CSI CUD when the renderer might be used to update a log leader, and your epiphany that it could be faster to update diagonally, we might be onto something.

One thing is certain: there’s more than one way to render, so loosely coupling the display and renderer(s) will be key.

I’m sure you noticed my diff that also introduced a Renderer to own the writer. It did not produce the effect I was looking for, but it is interesting that we both made things with the same name on the same day.

[kriskowal]

Also, when benchmarking, let’s keep in mind that cursor optimizations are designed mostly to reduce network traffic, so these apps perform alright over ssh. I’m not sure how relevant that is, but my assumption was that spending CPU time to avoid writing a lot was classically valuable.

24 bit color is very wasteful on the wire, but that’s irrelevant if we’re optimizing for fat clients that run locally. Do your benchmarks even reveal a performance gain in RenderOver vs Render? There might be more to gain from preparing the write buffer with reusable chunks than there is in preparing one-use cursor motions and only drawing invalidated cells.

[jcorbin]

Heh, great questions:

name                old time/op    new time/op    delta
_displayDemo/4-4      4.61µs ± 0%    3.70µs ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/8-4      16.3µs ± 0%    13.1µs ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/16-4     61.9µs ± 0%    50.2µs ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/32-4      244µs ± 0%     199µs ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/64-4      968µs ± 0%     794µs ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/128-4    3.89ms ± 0%    3.16ms ± 0%   ~     (p=1.000 n=1+1)
_displayDemo/256-4    15.8ms ± 0%    12.9ms ± 0%   ~     (p=1.000 n=1+1)

The "new" side just uses a single display and Render()s it every frame.

[kriskowal]

I think the conclusion is that we provide both Render and RenderOver, and let the developer decide whether size on wire is important. Do I read this right?

[jcorbin]

Unclear really; I'm dubious on exposing a front/back buffer and letting dev decide; would rather hide it, and switch to it by env detection and/or option.

…

On Sun, Dec 10, 2017 at 9:54 PM Kris Kowal ***@***.***> wrote: I think the conclusion is that we provide both Render and RenderOver, and let the developer decide whether size on wire is important. Do I read this right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADCM6wlZy4rpGRYIGO3YcgK7--Nro-wks5s_MNNgaJpZM4Q8Uyd> .

[kriskowal]

👍 Render sans RenderOver it shall be. On Sun, Dec 10, 2017 at 10:02 PM Joshua T Corbin <[email protected]> wrote:

…

Unclear really; I'm dubious on exposing a front/back buffer and letting dev decide; would rather hide it, and switch to it by env detection and/or option. On Sun, Dec 10, 2017 at 9:54 PM Kris Kowal ***@***.***> wrote: > I think the conclusion is that we provide both Render and RenderOver, and > let the developer decide whether size on wire is important. Do I read this > right? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#17 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AADCM6wlZy4rpGRYIGO3YcgK7--Nro-wks5s_MNNgaJpZM4Q8Uyd > > . > — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADrhvhqFw3i7TIU0crj4JxdJ3CO61GBks5s_MWLgaJpZM4Q8Uyd> .