[cairo] Wayland remote rendering: Cairo/Pango as Remote Calls over VNC

[Tarnyko]

Hi folks, 

Very interesting heads-up about the ctx graphics framework, thanks for 
lettings me/us now. 

As for Wayland remote rendering in general, you may be interested about the 
Waypipe project : 

https://mstoeckl.com/notes/gsoc/blog.html 

I exchanged a few messages with the author back then, and stopped -as demand 
is quite low. It's supposed to hook onto executables, but you may very well 
use it with a library. 

(here is a demo with a pure Wayland video player -Celluloid- running through 
a remote on the Weston compositor :
https://www.tarnyko.net/repo/waypipe.png ) 

Performance is quite good but maybe not optimized for this usage. 

Regards,
Tarnyko 

Øyvind Kolås writes: 

> On Mon, Aug 23, 2021 at 2:20 PM Rick van Rein <rick at openfortress.nl> wrote:
>> This gave me the idea that remote procedure calls for Cairo/Pango
>> APIs could support remote Wayland.  VNC may be designed for pixels,
>> but it is open to extensions and an RPC protocol could be added as
>> a pseudo-encoding for pixels.
> 
> I am working on and exerpimented with a project that among many other
> things is such a remote graphics protocol and renderer: 
> 
> https://ctx.graphics/ 
> 
> it is a ANSI standard terminal extended with modern a modern vector
> graphics protocol, similar to how terminals used to be graphical with
> regis/tektronix graphics. To me it is natural that it is possible to
> upgrade a terminal from text mode to graphics mode, just like one can
> upgrade the console of ones workstation from text mode to graphics
> mode. By using this terminal emulator directly on the framebuffer
> device; one gets the potential foundation of a multi-tasking desktop
> that uses significantly less RAM than GPU based compositing window
> managers allocating a texture per window (the model does support
> texture caching of clients - for now the caching happens for sub
> regions of the desktop across clients). 
> 
> All the post script derived imaging models of
> direct2d/quartz/pdf/cairo/html canvas are closely related, ctx aligns
> more closely with HTML5 Canvas 2D context than cairo; though it is
> inspired by both. Ctx also sports features like CMYK, floating point
> raster images and ICC color management on top of the base rendering
> capabilities.  See https://ctx.graphics/protocol/ for the actual
> protocol itself. In ctx' implementation read-back of graphics state is
> done locally instead of incurring round trips; if one ignores ability
> to read back graphics state really minimal minimal bindings are
> possible like this ctx implementation for bash:
> https://ctx.graphics/file/demos/ctx.bash.html 
> 
> Textures are transmitted in-band, this even works for low resolution
> video playback locally - but using a different transport or doing
> shared memory out-of-band when renderer and client are on the same
> machine similar to how the kitty terminal graphics protocol works will
> be desired or neccesary. 
> 
> ctx is fast compared with cairo; especially considering that the only
> SIMD support in ctx is from what memcpy provides. In benchmarks of
> source-over, source-copy permuted with color, linear, radial, nearest
> neighbour and bilinear patterns, the only cases where cairo/pixman is
> faster than ctx is for bilinear patterns, for all the other cases the
> combination of the faster (sometimes even more accurate) rasterizer
> and optimized portable C code of ctx wins. For the most common paint
> source, color fills, ctx is currently 1.8-3x faster than cairo, for
> gradients fills ctx is sometimes 10x faster. 
> 
> /pippin