Thank you Nick, indeed it worked. It is far better now :). Though there is
still a minor issue. It is the fact that some applications may become
incorrect if some events are ignored (the ones before view update at next
frame).
Meanwhile, I have been digging a bit and found one quite impressive
deb
That actually sounds like it works pretty well. Even though you are getting
multiple triggers, you are still preventing an enormous volume of mousemove
updates. (I am assuming the time until reactivation is relatively long).
The only thing that I would add is a filter on MoveMsg updates... if
`act
I have been trying something that I think could be shared.
Basically I tried to see if it was possible to throttle commands by
controlling the event attributes in the view that generate those commands.
Well, turns out, not really ^^. The idea was the following:
* In the model, have an attribute
Ok, thanks for the clarification Robin.
On Sun, Nov 20, 2016 at 8:32 AM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:
> It's specific to the virtual dom. Events are triggered as normal, but the
> code that renders the view is only called with the latest state once per
> frame.
>
>
> lørd
It's specific to the virtual dom. Events are triggered as normal, but the
code that renders the view is only called with the latest state once per
frame.
lørdag 19. november 2016 15.51.56 UTC+1 skrev Matthieu Pizenberg følgende:
>
> Hi everyone,
>
> I am currently developing some functionality t
