You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this first post I look back at what we achieved in 2024.
7
+
8
+
<!-- END_SUMMARY -->
9
+
10
+
11
+
## Some history
12
+
13
+
Korijn and I (Almar) have been working on Pygfx since 2020.
14
+
At the time, the development of WebGPU and ([wgpu-native](https://github.com/gfx-rs/wgpu-native)) was just getting started. Both WebGPU and Pygfx have come a long way since then.
15
+
In an earlier [post](https://almarklein.org/wgpu.html) I describe the origins of Pygfx from a more technical perspective.
16
+
17
+
For several years, our work was funded by the company that Korijn was
18
+
employed with. But this ended in 2024 when his division was disbanded for
19
+
corporate reasons.
20
+
21
+
To keep Pygfx going, we came up with the sponsorship model presented at this website.
22
+
Since we (the developers of Pygfx) now need to answer to multiple stakeholders,
23
+
it seems like a good idea to write regular status reports.
24
+
25
+
The idea of posts like this, is to provide insight into the
26
+
higher level perspective, design decisions, priorities, and
27
+
achievements. I plan to write one every one or two months or so.
28
+
29
+
30
+
## Overview of 2024
31
+
32
+
From the start of 2024, our goal was to move to a "1.0 release". With
33
+
this we mean that we wanted to implement crucial features, and address
34
+
the issues/features that would introduce backwards incompatibilities.
35
+
We summarized this in [issue #932](https://github.com/pygfx/pygfx/issues/392).
36
+
37
+
I'll briefly discuss the biggest chunks of work that we did in 2024.
38
+
39
+
40
+
### Buffer and texture updates
41
+
42
+
In [pr #795](https://github.com/pygfx/pygfx/pull/795) and later PR's, we
43
+
refactored large parts of the buffer and texture objects for more efficient
44
+
updates. Later we introduced a way to send data to a buffer/texture without
45
+
it being stored on the CPU in [pr #879](https://github.com/pygfx/pygfx/pull/879).
46
+
47
+
48
+
### Async support
49
+
50
+
Async is a tricky topic. The WebGPU API specifies some functions as being
51
+
asynchronous. The main reason for wanting to adhere to this, is
52
+
that it would allow us to use JavaScript's WebGPU API, which is necessary
53
+
if we ever want to support Pyodide/PyScript and run in the browser.
54
+
55
+
The tricky part is that async code tends to force other code to be async too.
56
+
And we did not want to force async on our users.
57
+
In [wgpu-py](https://github.com/pygfx/wgpu-py/) we addressed this by providing both
58
+
sync and async flavours for such functions.
59
+
In the [rendercanvas](https://github.com/pygfx/rendercanvas) we implemented an
60
+
awesome event-loop mechanism that supports both sync and async callbacks.
61
+
62
+
What's left (to do in 2025) is to combine this in Pygfx.
63
+
64
+
65
+
### Rendercanvas
66
+
67
+
This year we also moved the GUI subpackage out of wgpu-py, into its own library: `rendercanvas`.
68
+
The subpackage was getting more complex, and giving it its own repo gives it room
69
+
to grow.
70
+
71
+
The purpose or `rendercanvas` is to provide a canvas/window/widget to
72
+
render to with WebGPU. Improvements made since it has its own repo include: support for
73
+
Asyncio and Trio, more consistent behavior across backends, async
74
+
support, and sigint handling.
75
+
76
+
77
+
### Update propagation
78
+
79
+
In [issue #495](https://github.com/pygfx/pygfx/issues/495) we outlined a set of changes related to how things react to changes and user input. The plan touches the event system in `rendercanvas`, and how to use this in Pygfx.
80
+
Part of this plan is to better separate rendering from handling updates. The renderer and world objects
81
+
should not participate in the event system.
82
+
83
+
This is an ongoing effort, with most of the work done in `rendercanvas`,
84
+
but quite some work ahead in Pygfx. The refactoring of the renderer / viewport as part of [issue #492](https://github.com/pygfx/pygfx/issues/492) is closely related to this work.
85
+
86
+
87
+
### Plotting support
88
+
89
+
We implemented improvements to text, ticks (`Ruler` object), and grids.
90
+
The viewport work is also a prerequisite for proper support for subplots.
91
+
92
+
93
+
### Mesh rendering
94
+
95
+
While Korijn and I focussed on the above, Pan has made a lot of contributions
96
+
related to advanced mesh rendering, like environment maps, PBR materials, animations,
97
+
compliance with the gltf format, and more.
98
+
99
+
100
+
## Up next
101
+
102
+
In the [next post](report002.html) I talk about what we plan to work on in 2025.
0 commit comments