New Feature Request: Ability to reduce volume of animated elements

[JesseVent]

Hi Felix,

This package is a lifesaver, I have been looking for something to provide this kind of functionality in R for a long while now!

I'm using it to visualise a process that has over 20,000 cases and a large amount of activities, and just wondering if there is a way to reduce the on-screen animations rendered but at the same scale that the full event log would contain?

For an example if I run traffic_fines %>% animate_process() rendering the 10,000 different flows is very resource intensive on my machine and takes about 50 seconds to load, and I think that the same story could be told rendering a fraction of the cases as on screen elements.

I am using development ‘processanimateR’ version 1.0.0.9000

Just an idea for a new feature, unsure of complexity or feasibility

Thanks for your work!

[fmannhardt]

Thanks. Nice that it is useful.

Currently, the animation is not very good at a large scale since each case is represented by its own SVG shape and all the timings are pre-computed. Also, bupaR is not yet very efficient in its internal operations. I think due to dplyr sometimes the full log needs to be copied without it being necessary.

I wanted to look into that for some time, but never found the urgent need since most actual use cases can be reduced before it comes to rendering.

There are several ideas I have:

• Somehow pre-cluster the cases such that larger tokens represent groups and then use the package as-is on the smaller clustered data. Several problems with this option a) The cluster does not move at 'one time' but represents a range of cases at different times. So one thought I had, is to somehow represent the distribution in the token shape. Tokens are just SVG shapes, so wrt. the shape the package is quite flexible. This would also help with tokens on top of each other. b) Tokens may change speed etc. so it might be difficult to find clusters and detail is lost.

• Sampling, which is very easy to do but obviously looses information.

• Some commercial Process Mining offerings overcome this problem by dynamically merging tokens that are on top of each other. So while they are on top of each other they get merged and the token size increases. This is not very natural with the current rendering approach based on declarative SVG animations. It might be possible to pre-compute and dynamically hide and show tokens. Hidden tokens would not be rendered so should not cause performance issues (but they need to be in the DOM and the animation values are calculated). The alternative would be to switch to rendering in JavaScript.

What are your thought on this?

[JesseVent]

I've been thinking about this all week if there is a way to return the full results, but then when it comes to the animation using a sample to represent each case.

Getting pretty similar results to what I would be expecting using the below

library(tidyverse)
library(bupaR)
library(processanimateR)

event   <- traffic_fines %>% group_by(case_id) %>% 
  summarise(vector = paste(activity, collapse="-"))
events  <- event %>% group_by(vector) %>% sample_frac(.1)
results <- traffic_fines %>% filter_attributes(case_id %in% events$case_id)

ptm <- proc.time()
animate_process(results)
print(proc.time() - ptm)

ptm <- proc.time()
animate_process(traffic_fines)
print(proc.time() - ptm)

This way I am still using the same proportion of cases, but it would still be good if we could just apply the sampling to the elements when rendering the svg animation. I'm not really sure how else I could go about reducing events rendered without losing any important information.

[JesseVent]

Amazing job on the latest commit by the way! Animations are definitely a-lot smoother and stick to the lines heaps better

[fmannhardt]

Thanks. You can simplify your sampling code by using the sample_n function from bupaR. The scaling issues are currently not very high priority for me, but I will look into this when time allows.

There is also definitely some optimisation possible to make the rendering more efficient.

[JesseVent]

Thanks, I've also noticed small optimisations by removing the token opacity - removes the overhead of having to recalculate pixel updates for all the shapes impacted by a moving token.

[Criviere]

Your best bet is to play it over a longer period of time, for example: 3 minutes instead of 1