|
| 1 | +gui API |
| 2 | +======= |
| 3 | + |
| 4 | +.. currentmodule:: rendercanvas |
| 5 | + |
| 6 | +You can use vanilla wgpu for compute tasks and to render offscreen. To |
| 7 | +render to a window on screen we need a *canvas*. Since the Python |
| 8 | +ecosystem provides many different GUI toolkits, rendercanvas implements a base |
| 9 | +canvas class, and has builtin support for a few GUI toolkits. At the |
| 10 | +moment these include GLFW, Jupyter, Qt, and wx. |
| 11 | + |
| 12 | + |
| 13 | +The Canvas base classes |
| 14 | +----------------------- |
| 15 | + |
| 16 | +For each supported GUI toolkit there is a module that implements a ``WgpuCanvas`` class, |
| 17 | +which inherits from :class:`WgpuCanvasBase`, providing a common API. |
| 18 | +The GLFW, Qt, and Jupyter backends also inherit from :class:`WgpuAutoGui` to include |
| 19 | +support for events (interactivity). In the next sections we demonstrates the different |
| 20 | +canvas classes that you can use. |
| 21 | + |
| 22 | + |
| 23 | +The auto GUI backend |
| 24 | +-------------------- |
| 25 | + |
| 26 | +Generally the best approach for examples and small applications is to use the |
| 27 | +automatically selected GUI backend. This ensures that the code is portable |
| 28 | +across different machines and environments. Using ``rendercanvas.auto`` selects a |
| 29 | +suitable backend depending on the environment and more. See |
| 30 | +:ref:`interactive_use` for details. |
| 31 | + |
| 32 | +To implement interaction, the ``canvas`` has a :func:`WgpuAutoGui.handle_event()` method |
| 33 | +that can be overloaded. Alternatively you can use it's :func:`WgpuAutoGui.add_event_handler()` |
| 34 | +method. See the `event spec <https://jupyter-rfb.readthedocs.io/en/stable/events.html>`_ |
| 35 | +for details about the event objects. |
| 36 | + |
| 37 | + |
| 38 | +.. code-block:: py |
| 39 | +
|
| 40 | + from wgpu.gui.auto import WgpuCanvas, run, call_later |
| 41 | +
|
| 42 | + canvas = WgpuCanvas(title="Example") |
| 43 | + canvas.request_draw(your_draw_function) |
| 44 | +
|
| 45 | + run() |
| 46 | +
|
| 47 | +
|
| 48 | +Support for GLFW |
| 49 | +---------------- |
| 50 | + |
| 51 | +`GLFW <https://github.com/FlorianRhiem/pyGLFW>`_ is a lightweight windowing toolkit. |
| 52 | +Install it with ``pip install glfw``. The preferred approach is to use the auto backend, |
| 53 | +but you can replace ``from rendercanvas.auto`` with ``from rendercanvas.glfw`` to force using GLFW. |
| 54 | + |
| 55 | +.. code-block:: py |
| 56 | +
|
| 57 | + from wgpu.gui.glfw import WgpuCanvas, run, call_later |
| 58 | +
|
| 59 | + canvas = WgpuCanvas(title="Example") |
| 60 | + canvas.request_draw(your_draw_function) |
| 61 | +
|
| 62 | + run() |
| 63 | +
|
| 64 | +
|
| 65 | +Support for Qt |
| 66 | +-------------- |
| 67 | + |
| 68 | +There is support for PyQt5, PyQt6, PySide2 and PySide6. The rendercanvas library detects what |
| 69 | +library you are using by looking what module has been imported. |
| 70 | +For a toplevel widget, the ``rendercanvas.qt.WgpuCanvas`` class can be imported. If you want to |
| 71 | +embed the canvas as a subwidget, use ``rendercanvas.qt.WgpuWidget`` instead. |
| 72 | + |
| 73 | +Also see the `Qt triangle example <https://github.com/pygfx/wgpu-py/blob/main/examples/triangle_qt.py>`_ |
| 74 | +and `Qt triangle embed example <https://github.com/pygfx/wgpu-py/blob/main/examples/triangle_qt_embed.py>`_. |
| 75 | + |
| 76 | +.. code-block:: py |
| 77 | +
|
| 78 | + # Import any of the Qt libraries before importing the WgpuCanvas. |
| 79 | + # This way wgpu knows which Qt library to use. |
| 80 | + from PySide6 import QtWidgets |
| 81 | + from wgpu.gui.qt import WgpuCanvas |
| 82 | +
|
| 83 | + app = QtWidgets.QApplication([]) |
| 84 | +
|
| 85 | + # Instantiate the canvas |
| 86 | + canvas = WgpuCanvas(title="Example") |
| 87 | +
|
| 88 | + # Tell the canvas what drawing function to call |
| 89 | + canvas.request_draw(your_draw_function) |
| 90 | +
|
| 91 | + app.exec_() |
| 92 | +
|
| 93 | +
|
| 94 | +Support for wx |
| 95 | +-------------- |
| 96 | + |
| 97 | +There is support for embedding a wgpu visualization in wxPython. |
| 98 | +For a toplevel widget, the ``gui.wx.WgpuCanvas`` class can be imported. If you want to |
| 99 | +embed the canvas as a subwidget, use ``gui.wx.WgpuWidget`` instead. |
| 100 | + |
| 101 | +Also see the `wx triangle example <https://github.com/pygfx/wgpu-py/blob/main/examples/triangle_wx.py>`_ |
| 102 | +and `wx triangle embed example <https://github.com/pygfx/wgpu-py/blob/main/examples/triangle_wx_embed.py>`_. |
| 103 | + |
| 104 | +.. code-block:: py |
| 105 | +
|
| 106 | + import wx |
| 107 | + from wgpu.gui.wx import WgpuCanvas |
| 108 | +
|
| 109 | + app = wx.App() |
| 110 | +
|
| 111 | + # Instantiate the canvas |
| 112 | + canvas = WgpuCanvas(title="Example") |
| 113 | +
|
| 114 | + # Tell the canvas what drawing function to call |
| 115 | + canvas.request_draw(your_draw_function) |
| 116 | +
|
| 117 | + app.MainLoop() |
| 118 | +
|
| 119 | +
|
| 120 | +
|
| 121 | +Support for offscreen |
| 122 | +--------------------- |
| 123 | + |
| 124 | +You can also use a "fake" canvas to draw offscreen and get the result as a numpy array. |
| 125 | +Note that you can render to a texture without using any canvas |
| 126 | +object, but in some cases it's convenient to do so with a canvas-like API. |
| 127 | + |
| 128 | +.. code-block:: py |
| 129 | +
|
| 130 | + from wgpu.gui.offscreen import WgpuCanvas |
| 131 | +
|
| 132 | + # Instantiate the canvas |
| 133 | + canvas = WgpuCanvas(size=(500, 400), pixel_ratio=1) |
| 134 | +
|
| 135 | + # ... |
| 136 | +
|
| 137 | + # Tell the canvas what drawing function to call |
| 138 | + canvas.request_draw(your_draw_function) |
| 139 | +
|
| 140 | + # Perform a draw |
| 141 | + array = canvas.draw() # numpy array with shape (400, 500, 4) |
| 142 | +
|
| 143 | +
|
| 144 | +Support for Jupyter lab and notebook |
| 145 | +------------------------------------ |
| 146 | + |
| 147 | +WGPU can be used in Jupyter lab and the Jupyter notebook. This canvas |
| 148 | +is based on `jupyter_rfb <https://github.com/vispy/jupyter_rfb>`_, an ipywidget |
| 149 | +subclass implementing a remote frame-buffer. There are also some `wgpu examples <https://jupyter-rfb.readthedocs.io/en/stable/examples/>`_. |
| 150 | + |
| 151 | +.. code-block:: py |
| 152 | +
|
| 153 | + # from wgpu.gui.jupyter import WgpuCanvas # Direct approach |
| 154 | + from wgpu.gui.auto import WgpuCanvas # Approach compatible with desktop usage |
| 155 | +
|
| 156 | + canvas = WgpuCanvas() |
| 157 | +
|
| 158 | + # ... wgpu code |
| 159 | +
|
| 160 | + canvas # Use as cell output |
| 161 | +
|
| 162 | +
|
| 163 | +.. _interactive_use: |
| 164 | + |
| 165 | +Using a canvas interactively |
| 166 | +---------------------------- |
| 167 | + |
| 168 | +The rendercanvas gui's are designed to support interactive use. Firstly, this is |
| 169 | +realized by automatically selecting the appropriate GUI backend. Secondly, the |
| 170 | +``run()`` function (which normally enters the event-loop) does nothing in an |
| 171 | +interactive session. |
| 172 | + |
| 173 | +Many interactive environments have some sort of GUI support, allowing the repl |
| 174 | +to stay active (i.e. you can run new code), while the GUI windows is also alive. |
| 175 | +In rendercanvas we try to select the GUI that matches the current environment. |
| 176 | + |
| 177 | +On ``jupyter notebook`` and ``jupyter lab`` the jupyter backend (i.e. |
| 178 | +``jupyter_rfb``) is normally selected. When you are using ``%gui qt``, rendercanvas will |
| 179 | +honor that and use Qt instead. |
| 180 | + |
| 181 | +On ``jupyter console`` and ``qtconsole``, the kernel is the same as in ``jupyter notebook``, |
| 182 | +making it (about) impossible to tell that we cannot actually use |
| 183 | +ipywidgets. So it will try to use ``jupyter_rfb``, but cannot render anything. |
| 184 | +It's theefore advised to either use ``%gui qt`` or set the ``WGPU_GUI_BACKEND`` env var |
| 185 | +to "glfw". The latter option works well, because these kernels *do* have a |
| 186 | +running asyncio event loop! |
| 187 | + |
| 188 | +On other environments that have a running ``asyncio`` loop, the glfw backend is |
| 189 | +preferred. E.g on ``ptpython --asyncio``. |
| 190 | + |
| 191 | +On IPython (the old-school terminal app) it's advised to use ``%gui qt`` (or |
| 192 | +``--gui qt``). It seems not possible to have a running asyncio loop here. |
| 193 | + |
| 194 | +On IDE's like Spyder or Pyzo, rendercanvas detects the integrated GUI, running on |
| 195 | +glfw if asyncio is enabled or Qt if a qt app is running. |
| 196 | + |
| 197 | +On an interactive session without GUI support, one must call ``run()`` to make |
| 198 | +the canvases interactive. This enters the main loop, which prevents entering new |
| 199 | +code. Once all canvases are closed, the loop returns. If you make new canvases |
| 200 | +afterwards, you can call ``run()`` again. This is similar to ``plt.show()`` in Matplotlib. |
0 commit comments