Is `Context` needed for anything other than performance?

[madsmtm]

I've read #37 and #64, and from my understanding, the split between Context and Surface is purely for performance, to allow sharing resources that are expensive to create.

Is that correct?

If so, then I feel it might make sense to add a convenience wrapper like:

impl<W: HasDisplayHandle + HasWindowHandle> Surface<W, W> {
    pub fn new_single_window_bikeshed(window: W) -> Result<Self, CreationError> {
        // Conceptual implementation, needs to be done differently in reality
        // since the window needs to only be stored in the surface.
        let context = Context::new(window);
        Self::new(&context, window)
    }
}

And perhaps change Surface to be something like struct Surface<D, W = D> (make the two type parameters default to be the same type).

This would simplify the common use-case of having a single window to be:

struct App {
    surface: softbuffer::Surface<winit::Window>,
    // + possibly an `Option` if you want to support Android too.
}

While still allowing the more complex multi-window case:

struct App {
    context: softbuffer::Context<winit::OwnedDisplayHandle>,
    surfaces: Vec<softbuffer::Surface<winit::OwnedDisplayHandle, winit::Window>>,
}

See relatedly #298.

[notgull]

I would be fine with adding this API.

[MarijnS95]

With the recent request/idea to possibly let users create and present buffers "separate" from their surface, note that those are not compatible across connections/contexts.

But that should be obvious when a buffer could only be allocated from a specific Context object to begin with. Should there be a Surface::context() getter then?