Custom event expiration? Event debouncing?

[yrashk]

I have a fairly specific case where I am trying to use an FTXUI component to render a fast-moving log stream. Whenever a new record arrives, a thread will post a Custom event. That would trigger the re-rendering, which is, I believe, at times of high volume streaming excessively unnecessary for the following reasons:

1. If the component is trying to catch up, posting multiple events on every new record makes a re-render happen on the same data set if OnEvent is called after a few events are posted.
2. the component only shows a few last records anyway, so there's no point in the earlier events if the component is catching up.

Since the producer doesn't know where the component is regarding catching up, it is difficult to control this pressure on the producer's side.

So I was thinking about options here.

One option is to encode somehow when an event of a certain type (see a link to another discussion below) is no longer of interest. But that's difficult; it forces us to carefully design complex custom events and event expiration. It may also depend on the consumer's point of view when the event actually expires.

Another (perhaps simpler?) option is to denote some events as debouncable; if it is produced more than once while there is another message of the same type, it is dropped. It still likely requires a way to introduce tagged events of a sort (see #677) just so that they can be separated from others. Thinking in the context of #677, what if it not only had a tag but a debounce flag?

Any thoughts?

This is tangentially related to #676

[ArthurSonzogni]

Hi @yrashk,
Thanks for starting this discussion and your support!

To release event pressure, FTXUI only draw a new frame after it has consumed every pending events:
source

void ScreenInteractive::RunOnce(Component component) {
  Task task;
  while (task_receiver_->ReceiveNonBlocking(&task)) {
    HandleTask(component, task);
    ExecuteSignalHandlers();
  }
  Draw(std::move(component));
}

It means FTXUI is always going to be able to adapt, even if you send 10000 events per seconds.

You can try this demo:
If you move the mouse sufficiently fast, you will see the ftxui event count higher than the ftxui frame count.

Of course this works only if "handling one event" is sufficiently fast. If you only want to flag the current frame as "dirty" and do not need to propagate the event inside deeply nested UI, you might want to try:

  void ScreenInteractive::RequestAnimationFrame();

instead?

Do you think this address your request?

[yrashk]

Thank you for such a prompt response!

Maybe I still do not fully understand it, but I suspect this is not a good solution yet. The stream I get comes in bursts, and it is unpredictable, so the producer doesn't know when to stop the propagation (will there be more coming right away? Who knows) unless it does some pressure control on its own.

I'll try to run with what is there right now, but I think I've seen the UI choke a bit at times on high loads, but I want to test more.