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 debouncing and throttling package [1]. It is based on controlling not the event listener with the view attributes but controlling the messages after they have been captured in the update method. It is kind of logic if you think of debouncing, you will need those events (otherwise there is nothing to "debounce" ^^). In sum, the advantages and issues of these methods might be the following: My method (controlling the view event listener) *advantages* : * Complete remove of the events. Can be a relief for the CPU in case of many events to throttle. My method (controlling the view event listener) *issues* : * Not able to deal with debouncing (since the events do not exist). * Possible wrong states created because of ignored events (I guess a work around could be done here to pass all events that have been ignored also). Jinjor package method (controlling the events after trigger) *advantages* : * Ability to deal with a wider range of message control (debounce, throttle, manual, etc). * No wrong state possible since we can batch process all ignored events (or just care about the last one). Jinjor package method (controlling the events after trigger) *issues* : * Possible CPU overload ? (if many frequent events need debouncing/throttle) -> to be checked, maybe computers nowadays are fast enough for any sane amount of those debouncing mechanics. * Possible memory overload ? For big delays the amount of messages to keep in memory until next debounce/throttle can grow huge. But this is not fair comparison since it would also be the case in my method if I had to deal with debouncing. Again, this would have to be checked. [1] http://package.elm-lang.org/packages/jinjor/elm-debounce/latest On Nov 21, 2016 08:57, "Nick H" <falling.maso...@gmail.com> wrote: > 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 > `active` is already set to False, ignore the MoveMsg update entirely. That > way you guarantee you aren't triggering multiple calls to Reactivate. > > > On Sun, Nov 20, 2016 at 1:24 AM, Matthieu Pizenberg < > matthieu.pizenb...@gmail.com> wrote: > >> 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 `active : Boolean` initialized at True >> (meaning that the event will trigger). >> * In the `MoveMsg` case of update function, set `active` to False and >> create a command that will reactivate it later in some time. >> * In the `Reactivate` case of update, reset `active` to True. >> * In the view, use `div [on "mousemove" ...] [...]` if active else `div >> [] [...]` >> >> This almost work (so it doesn't ^^). Since mouse events can be triggered >> more often than the rendering of the view, multiple mousemove events can be >> triggered before the `[on "mousmove" ...]` is removed. >> In practice the longer the functon in your mousemove update, the higher >> are the chance that I got these multiple trigger before deactivation of the >> listener. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elm-discuss+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit https://groups.google.com/d/to > pic/elm-discuss/WSMyDrpPs7s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
