transitions make brushing sluggish

[gordonwoodhull]

Currently if you move the brush slowly enough that lots of small changes get through the throttle, it ends up queuing up a very long transition that's way behind the actual current brush location. Then it suddenly transitions to the current location whenever you let go.

During a brush action, you probably only want a transition to the first brush location that gets through. Then update without transitions for any further brush actions until brushend.

Or have a much shorter transition duration for transitions during brushing.

This would combine the (usually nice) transitions that dc.js provides with the speed of reaction and raw performance that the original crossfilter demo has.

This doesn't solve all sluggish behavior, just things where the data set is small but the dc.js brush nevertheless doesn't seem to be keeping up.

The other dc.js feature that makes brushing sluggish is the throttle #630

For example if you add

.transitionDuration(100)

to all the charts in the stock example, and remove the other transitionDurations, and also remove the throttle with

dc.constants.EVENT_DELAY = 0;

the brushing performs much better.

Of course, the click filtering on everything else becomes incomprehensible. 😄

All charts should use the regular transitionDuration when the brush start event occurs, as with all non-brush filter events, but all charts might also have a second brushTransitionDuration which is used whenever the cause of a redraw is a brush brush or end event. Currently there is no way to know, so evidently chart registry events need parameters?

[kum-deepak]

In addition in focus/range chart pairs - switching off transitions completely during brushing and zooming will provide much better user experience.

[kum-deepak]

I think with my current understanding I can take a stab at it.

Initially I will try to completely switch off transitions while brushing/zooming - during this phase the range/focus charts will update on the fly and redrawAll for other charts will be debounced.

If the above does not work with adequate performance, while brushing/zooming I will throttle (may be like 20-40ms - to give 50-25 fps) range/focus charts updates.

Most likely this will end up configurable for the chart pair - no throttle or throttle time in ms.

I will work on this once debounce and throttle have been merged in.

[skybitsindri]

Are you able to achieve

"If the above does not work with adequate performance, while brushing/zooming I will throttle (maybe like 20-40ms - to give 50-25 fps) range/focus charts updates."

I am looking for a throttle based solution in case of brush movement cause data is big data & each brush is triggering a network call. I tried events.trigger but this only delays which don't show me the transition rather only the last point where I leave the brush.

My concern is reducing the network call as-well-as smooth transition (i don't mind interval-based like for whole brush movement time of 1 sec (continuous movement) then at each 100 ms network call triggered)

[gordonwoodhull]

Hi @skybitsindri, that’s an important question but it’s unrelated to this issue, where the response from the backend is still reasonable for interactive use but the transitions screw it up.

Sounds like you probably want #627 / #898 filtering only on brushend. I think that PR could be merged but it needs some review.

If you want to investigate better throttling that is discussed in #630. I’ve not seen any contributions on that front.

[skybitsindri]

@gordonwoodhull , thanks for the reply

I mean looking to time series analysis. so could be good the other chart change as brush move rather than brush end.

#630 is what I am looking for. Let me check if I can contribute if I come up with anything