1
1
.. currentmodule :: matplotlib
2
2
3
3
.. _mpl-shell :
4
+
4
5
===================
5
6
Interactive plots
6
7
===================
13
14
14
15
15
16
By default, matplotlib defers drawing until explicitly asked. Drawing
16
- can be an expensive operation, and you do not want to re-render the
17
- figure every time a single property is changed, only once after all
18
- the properties have changed and the figure is displayed on the screen
19
- or saved to disk. When working in a shell, one typically wants the
20
- figure to re-draw after every user command (ex when the prompt comes
21
- back). *interactive * mode of :mod: `~.pyplot ` takes care of arranging
22
- such that if any open figures are :ref: `stale <stale_artists >`, they
23
- will be re-drawn just before the prompt is returned to the user.
17
+ may be an expensive operation and some changes to the figure may leave
18
+ it in an inconsistent state, hence we only want to render the figure
19
+ just before the figure is displayed on the screen or saved to disk.
20
+ In the case of scripts this is easy to arrange, we simple do nothing
21
+ until ``savefig `` is called. However, when working interactively,
22
+ either at a terminal or in a notebook, we would like the figure to
23
+ automatically re-render when we change. Further, we would like the
24
+ figures respond to user input (mouse and keyboard) to interact with
25
+ and explore the data.
26
+
27
+ To get this functionality we need a combination of an interactive
28
+ backend (to handle the user interaction with the figure) and an
29
+ interactive interpreter (to handle the input of user code). Together
30
+ these tools need to:
31
+
32
+ - Take text from the user and execute it in the Python interpreter
33
+ - Ensure that any created figures are put on the screen
34
+ - Trigger a re-render of the figure when the user has mutated it
35
+ - When not actively executing user input, run the event loop so we can
36
+ get user input on the figure (see
37
+ :ref: `interactive_figures_and_eventloops ` for details)
38
+
39
+
24
40
25
41
.. _ipython-pylab :
26
42
27
- IPython to the rescue
28
- =====================
43
+ IPython to the rescue!
44
+ ======================
45
+
46
+ To support interactive
29
47
30
48
We recommend using IPython for an interactive shell. In addition to
31
49
all of it's features (improved tab-completion, magics,
@@ -72,7 +90,7 @@ will be reflected immediately.
72
90
73
91
.. _other-shells :
74
92
75
- Other python interpreters
93
+ Other Python interpreters
76
94
=========================
77
95
78
96
If you can not or do not want to use IPython, interactive mode
@@ -99,6 +117,72 @@ interactive shell is run in a sub process of the GUI and you can use
99
117
any backend.
100
118
101
119
120
+ PyCharm
121
+ -------
122
+
123
+ TODO: links to pycharm docs on configuring Matplotlib backends
124
+
125
+ Spyder
126
+ ------
127
+
128
+ TODO: links to spyder docs on configuring Matplotlib backends
129
+
130
+ VSCode
131
+ ------
132
+
133
+ TODO: links to vscode docs on configuring Matplotlib backends (?)
134
+
135
+
136
+ Jupyter Notebooks / Jupyter Lab
137
+ -------------------------------
138
+
139
+ .. warning ::
140
+
141
+ To get the interactive functionality described here, you must be
142
+ using an interactive backend, however he 'inline' backend is not.
143
+ It renders the figure once and inserts a static image into the
144
+ notebook everytime the cell in run. Being static these plots can
145
+ not be panned / zoomed or take user input.
146
+
147
+ Jupyter uses a different architecture than a traditional interactive
148
+ terminal. Rather than the user interface running in the same process
149
+ as your interpreter, the user interacts with a javascript front end
150
+ running in a browser which communicates with a server which in turn
151
+ communicates with a kernel that actually runs the python. This means
152
+ for interactive figures our UI needs to also be written in javascript
153
+ and run inside of the jupyter front end.
154
+
155
+ To get interactive figures in the 'classic' notebook or jupyter lab use
156
+ the `ipympl ` backend (must be installed separately) which uses the `ipywidget `
157
+ framework and which enabled by using ::
158
+
159
+ %matplotlib widget
160
+
161
+ If you only need to use the classic notebook you can also use ::
162
+
163
+ %matplotlib notebook
164
+
165
+ which uses the `nbagg ` backend which ships with Matplotlib (but does
166
+ not work with JLab because, for security reasons, you can no longer
167
+ inject arbitrary javascript into the front end).
168
+
169
+ GUIs + jupyter
170
+ ~~~~~~~~~~~~~~
171
+
172
+ If you are running your jupyter server locally you can use one of the
173
+ GUI backends, however if you ever move that notebook to a remote
174
+ server it will cease to work correctly. What is happening is that
175
+ when you create a figure the process running your kernel creates and
176
+ shows a GUI window. If that process is on the same computer as you,
177
+ then you will see it, however if it is running on a remote computer it
178
+ will try to open the GUI window on _that_ computer. This will either
179
+ fail by raising an exception (as many linux servers do not have an
180
+ XServer running) or run cleanly, but leave you with no way to access
181
+ your figure.
182
+
183
+
184
+
185
+
102
186
.. _controlling-interactive :
103
187
104
188
Controlling interactive updating
0 commit comments