Design of GraphicsBackend trait

[elinorbgr]

Design of GraphicsBackend trait

[Drakulix]

Once textures are supported softrenderer looks also like a useful debugging and fallback graphical backend.

[Drakulix]

handling resize of the backend surface (when running embedded, as glutin/x11/wayland)
handling modesetting (for the tty backend)

I would suggest, we just don't handle these in the general trait. Instead handle them in the specific backend type.

support opengl-less setups?

I was asking myself if this is possible. Almost every compositor uses gles, is this a requirement? If it is not, I would like to experiment with vulkano for example in the future.

I was thinking if the GraphicsBackend should maybe be just a generic output to render on, that is actually implemented by a sub type of the actual backend types.

E.g.

pub trait Output
{
    fn render(&mut self, buffer: &[u8], format: FormatEnum);
    fn swap(&mut self);
}

pub struct GlutinBackend;
impl GlutinBackend
{
    fn create_output(&mut self) -> GlutinOutput;
}

pub struct GlutinOutput(GlutinWindow);
impl Output for GlutinOutput {
    /// implementation
}

pub struct DrmBackend<H: DrmHandler>(H);
impl<H: DrmHandler> DrmBackend<H> {
    fn new(handler: H) -> DrmBackend<H> {
        DrmBackend(handler)
    }
}

pub trait DrmHandler
{
    //warning we should probably not transfer ownership here, consider this an example
    //that every backend may work totally differently
    fn output_attached(&mut self, output: DrmOutput);
    fn output_detached(&mut self, output DrmOutput);
}

pub struct DrmOutput;

impl Output for DrmOutput
{
    // implementation
}

[elinorbgr]

I think it'll be necessary to separate into different traits depending on the rendering kind: cpu rendering vs OpenGL rendering (vs vulkan ?), rather than a single generic Output trait.

Something along the lines of

trait CpuRender {
    fn render(&mut self, buffer: &[u8], format: Format);
}

trait OpenGlRender {
    // Direct access to the OpenGL context, the caller is responsible for doing whatever
    // they need to draw, swap_buffers, and everything
}

I'm not sure what exactly should go in the OpenGlRender trait, but as a rule of thumb, I'd say we should at least be able to impl the Backend trait of glium on top of it:

impl<B: OpenGlRender> glium::backend::Backend for B {
    ...
}

[Drakulix]

Thats a totally different idea. I thought we want to hide how the rendering itself works and just pass the buffers into it.
Exposing the rendering framework over the backend and let the user take complete control over the rendering process is also a cool idea.
I think I like you approach better, after all I did criticize wlc for it's abstractions. Do we actually need a rendering trait like this?

[elinorbgr]

Not sure actually, about what traits are needed.

However, my global course of action would be to first define the lowest-possible abstractions, and then if applicable build more high-level abstractions on top of them.

I don't want to reach a point where performance is terrible because the abstractions where badly designed. And for example, if we want to support EGL from clients, the ability to play nice with mesa and pass around drm buffers from the clients directly to our opengl renderer is crutial.

Also, the backend should not make any assumption about what the user draws will look like. After all,a 3D environment is a perfectly valid compositor !

[Drakulix]

Alright, so maybe we should not start with any GraphicsTrait, but instead just provide something to render at first and experiment with multiple backends.

[elinorbgr]

Maybe we could indeed just develop the backends, and then try to build a common abstraction over them. It'll probably be a much easier route.

Do you want to start takling the glutin backend? For now I think I'll focus on implementing the missing bits of wayland-server, and the client-handling part.

[Drakulix]

Do you want to start takling the glutin backend? For now I think I'll focus on implementing the missing bits of wayland-server, and the client-handling part.

Sure thing. But I would also like to have a Discussion issue on the wayland side, if you already know, what needs to be done. The sooner, I have something to actually render, the easier writing the backends will be, so I will maybe help you with some of the wayland related issues to have something to test with.

[elinorbgr]

You're right, I'll create an issue about that and put in there what I already know.

[Drakulix]

Just a quick update, I was quite busy the last days with changing my linux distribution on my laptop and some work related stuff, I will probably start with the glutin backend this evening.

[elinorbgr]

Okay, no problem, I'm quite busy these days too to be honest.

[elinorbgr]

Looks like we settled on something. :)