Add mpl-playback to widgets gallery examples
#23441
Conversation
|
I'm of course 💯 for, but you may want to put this on a call discussion if you can make any of 'em? ETA: I think typing would be nice, but hasn't been a criteria for dependencies so not sure that should hold things up. |
|
Rendered example and thumbnail in gallery
Good point!
For whatever reason Thursday tends to be a really good day for us to run experiments so it's unlikely (though not impossible) that I'll be able to for a few weeks. But then there's also no big rush here ooh I also might like to improve the rendering of the fake cursor which is currently just a triangle. |
|
I'm +1 on this. Do you have an estimate how log the example generation takes? |
This is dependent on few settings like Those draws are happening here: https://github.com/ianhi/mpl-playback/blob/06a7faf567e487b49d32468767fd90fb5f659ec9/mpl_playback/playback.py#L245-L248 |
|
As you know of course, I'm in favour of this. I wonder if we can get away with something like 12 fps, both for speed and size reasons. It's not a full movie, so we might not need a high frame rate. |
|
A naive calculation gives: That'd be a lot. If we plan to use this in multiple examples, we definitively need to pull in some of the discussed (or other) performance optimizations. |
|
Is there a way to make CI build them much more sparsely (maybe even a snapshot) and the deployed builds take the time to make the full-res movie? |
One can probably influence the behavior via an environment variable. |
|
You can probably check if the figure is stale right before you grab the frame and if so, only call draw then. |
Current PR statusQuick update for anyone stumbling across this PR. The next steps involve making performance improvements to mpl-playback. Unfortunately I don't expect to have much time to focus on that for at least several months (trying to finish my graduate program!). That said I would be happy to review and merge PRs with any performance improvements! I made an issue to track and discuss such improvements here: mpl-extensions/mpl-playback#19 thoughts and PRs most welcome. |
|
I'll move to draft, but please consider closing if this will not be done in a finite time window. |
|
with mpl-extensions/mpl-playback#20 (inspired by @story645 ) |
|
Whats a reasonable time across the widget examples to aim for? Also potentially there could be a build flag where this is run only on production builds or certain PRs? |
For release builds, the time does not matter. Only size may need to be considered. Our current CI doc builds take about 30min, which is already far too long and we should look into ways to trim this down. As a rule of thumb, I wouldn't spend much more than one minute on this for CI doc builds. One can achive this through further speedup and/or only selecting few examples.
That's certainly useful. |
|
At the scipy sprints @QuLogic and @story645 helped me look at this a bit and we came to following conclusions:
With the speed improvements and thoughtful recordings of examples I suspect we could get to only 5-10 seconds of generation per example. So that leaves the question to be answered as: "Is that fast enough". and/or are we ok with having the gifs build only on release builds (i.e. devdocs)? |
So I think at sprints @ianhi got it down to about 4 minutes, which I think for doc release builds is well worth it for being able to demonstrate the interactivity of the library. ETA: I think only issue there is maybe low bandwidth situations where we'd want to default to thumbnails, but this is also true for animations. It'd be awesome if we could limit this to only run when files in widget/event or a subset of narrative docs are changed, but I think that could also be a follow up optimization...or maybe a standalone action that just calls sphinx playback w/ changed files & shows the output so that it's available for reviewers? Which I think is a riff on #23441 (comment) (No idea if that's doable...) ETA:
I think the auto labeler may be doing this? Or it's doing something based on changed files rather than labels: https://github.com/matplotlib/matplotlib/blob/main/.github/labeler.yml |
👍
It's less a problem because we have incremental loading of images now. One could try and inject static thumbnails, but that's only half the fun. Separate topic (completely optional just in case anybody is interested): You could detect the speed either through Network Information API (limited support, but if your browser has it, you'd get the benefit of less-volume downloads) or other client-side detection methods. |
PR Summary
Start using
mpl-playback(docs, github) to automatically generate GIFs of interactions with widgets for sphinx-gallery. This works by:jsonfilesphinx-galleryscraper to turn thosejsonfiles intogifs when the docs buildThe built version looks like this: Rendered example and thumbnail in gallery.
I've made a recording of the slider demo for this PR which currently looks like this:
This will close: #19222
Discussion!
I'm opening this early to see if this is something that the core devs would be interested in. As it stands I don't think
mpl-playbackis quite ready for mpl to depend on it. But I'd be happy to put in the work to make sure it is if the consensus would be to go ahead with this. I will note that this is hopefully a very low cost addition, at any point it's a one line change to go back to the default sphinx-gallery behavior.If this is desirable I'd be interested in hearing what the criteria
mpl-playbackwould need to reach in order to be an acceptable dependency. The main things that I would like to improve on:playbackcapability, butrecordis untested(I'd be happy for PRs of course :) )
PR Checklist
Tests and Styling
pytestpasses).flake8-docstringsand runflake8 --docstring-convention=all).Documentation
doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).