Scientific figures, as complex as they might be, always end up being made of a (large) set of elementary graphical components, namely points (or markers), lines, glyphs (text), polygons, and volumes. Glyphs, markers and polygons can be further decomposed into triangles such that, apart from the specific case of 3D volume rendering, the elementary components of most scientific figures are essentially points, lines and triangles.

When designing a scientific figure, one rarely manipulates these components explicitly. Instead, one uses high-level plotting functions that ultimately produce these elementary components. What defines a scientific visualization library is the choice and the definition of these high-level functions. The library may provide high-level functions that allow them to quickly design a figure (e.g. ggplot, vega, seaborn), or lower-level functions that allows them to further tune the figure (e.g. matplotlib, vispy). In the most extreme case, the user may even be provided a total freedom at the price of complexity (TikZ). There is no definitive one-size-fits-all API because some users prefer the simplicity of a high-level interface that makes most decisions transparently, while others prefer to have a total control of all aspects of the figure.

In all cases, however, the rendering task is the same: drawing points, lines, markers, glyphs, polygons, meshes and volumes as efficiently as possible, possibly taking advantage of low-level libraries and hardware. Ultimately, rendering represents significantly redundant efforts across visualization libraries, and it becomes increasingly complex when considering low-level hardware-accelerated graphics interfaces such as OpenGL, Metal, DirectX, or Vulkan. Our experience with the development of hardware-accelerated scientific visualization libraries such as glumpy, galry, and vispy has shown that this complexity is a significant obstacle to the development of an efficient and scalable scientific visualization library in Python.

The graphic server protocol is a proposal to mutualize efforts across scientific visualization libraries, languages and platforms such as to provide a unified intermediate-level protocol to render graphical primitives independently of the specifics of the high-level visualization interfaces. The goal is not to provide yet another graphical library, but a foundational protocol-based architecture that any scientific visualization library can reuse.

During this talk, we will introduce the graphical server protocol we have designed and show a couple of early examples using two different rendering backends: matplotlib and Datoviz (which is based on Vulkan, a low-level interface for high-performance rendering and computing using GPUs). These two backends will render the same figure with the same visual quality using the same Python script, even though the Vulkan backend is expected to be significantly faster than the matplotlib one. Currently, the matplotlib instance can produce 3D graphics (meshes, surfaces and volumes) even though it is limited by the absence of a depth buffer that prevents proper sorting. The roadmap for the protocol is still largely open and we would like to gather feedback from developers of other scientific visualization libraries to potentially create an international steering group that could help define the roadmap.