Re: [9front] Thoughts on Wayland?

[ori@eigenstate.org]

shared memory just isn't a very good model for distributed systems.

devdraw is more or less what you get if you make a slimmed down cairo
the native drawing model, and talk to it over a pipe for rpcs, but your
musings are gradually reinventing devdraw :)

Quoth Willow Liquorice <willow@howhill.com>:
> I gave this some more thought, and "just shim Cairo" has a lot of 
> potential footguns, and it comes down to memory (again). What if you 
> tried using one of the functions in memory(2) – common to both OSs – on 
> a piece of memory that is touched by Cairo (and is, therefore, remote).

cairo supports many backends; a devdraw backend would not be that
difficult; shared memory is not necessary.

A good one would be harder, but even so it would not be that bad;
devdraw's model is still a reasonable fit for cairo -- there are
several missing features, but the model matches. Specifically,
off the top of my head, cairo would need:

	* scaling matrices
	* antialiasing
	* gradients

as devdraw rpcs, and then cairo could do all of the heavy lifting
in devdraw.
 
> On 04/08/2024 22:10, Willow Liquorice wrote:
> > It sounds like the "shared memory" concept Wayland uses is the tricky 
> > bit, then, because you can't put the same RAM stick in two different 
> > machines.
> > 
> > Though, if I'm understanding pipe(3) correctly, it reads like the right 
> > tool to talk to the compositor.
> > 
> > Thinking about it, I guess the compositor and the in-use graphics 
> > resources (hardware, software, data) ought to be resident on the same 
> > physical system: a "GPU server", by analogy with a CPU server, though 
> > "composition server" is probably a more accurate term.
> > 
> > Thinking about it even more, if *all* graphics resources, in use or not, 
> > are resident on the GPU server, you don't have to shove huge fonts or 
> > textures over the network, just the rendered images (or diffs!) and some 
> > RPCs to a process resident on the GPU server to get it drawing what you 
> > want.
> > 
> > How on earth that makes a program that uses Pango+Cairo, or something 
> > like that, play nicely on 9 I have no idea… more shims for client programs?
> > 
> > I suppose every terminal is, in and of itself, a GPU server. Maybe I'm 
> > overthinking it.
> > 
> > On 04/08/2024 20:59, Eli Cohen wrote:
> >> actually, drawing fast locally (and GPU stuff especially for
> >> computation) is definitely a plan 9 concept too and is also being
> >> worked on separately from wayland, and possibly on linux... so... plan
> >> 9 is an OS for networks that may include plan 9 machines, linux
> >> machines, iPhones, etc... it's a "unix made out of a network of
> >> computers" not a "network made out of unix computers"
> >>
> >> On Sun, Aug 4, 2024 at 12:54 PM Eli Cohen <echoline@gmail.com> wrote:
> >>>
> >>> always better to be a willow that bends than the strongest oak in a 
> >>> storm :)
> >>>
> >>> there's a common misconception that plan 9 is an OS for a computer. 
> >>> plan 9 is an OS for a network. drawing fast locally is not a plan 9 
> >>> concept. plan 9 is a 9P multiplexer. a wayland shim for 
> >>> linux/mac/bsd/etc that renders to draw somewhere else on the network 
> >>> would be good and appreciated and a relevant plan 9 concept and 
> >>> people are working on it... but for a fast local wayland 
> >>> implementation, that's what linux is, and linux can be and is a part 
> >>> of plan 9 which is an OS for a network
> >>>
> >>> On Sun, Aug 4, 2024, 12:46 PM Stuart Morrow <morrow.stuart@gmail.com> 
> >>> wrote:
> >>>>
> >>>> How do you share memory over rcpu?