x/exp/shiny: x11driver makes it impossible to implement screen.Buffer

[jnjackins]

I have a type (a graphical widget) that implements screen.Buffer, which I've been using happily with gldriver, under darwin. The documentation is here, and there is an example program sigint.ca/graphics/editor/example/multi if you are interested.

The widget is implemented as a type Editor which implements screen.Buffer, and is drawn to a shiny window as follows:

widget := editor.NewEditor(size, font, nil)
...
win.Upload(image.ZP, widget, widget.Bounds())

However, when I tested my code on linux recently, I quickly ran into a problem:

func (w *windowImpl) Upload(dp image.Point, src screen.Buffer, sr image.Rectangle) {
    src.(*bufferImpl).upload(w, xproto.Drawable(w.xw), w.xg, w.s.xsi.RootDepth, dp, sr)
}

Unlike gldriver, methods implemented by x11driver assume that any screen.Buffer, screen.Texture, etc. passed to them are the implementations provided by x11driver, and panic when they are not.

Is this restriction necessary? Should I rethink my strategy? Why provide an interface if it's not allowed to be implemented?

[jnjackins]

FYI @nigeltao @crawshaw

[nigeltao]

The interface is provided because the screen package is not specific to any one driver: the x11driver buffer implementation is not the same as the gldriver buffer implementation. Nonetheless, the Screen.NewBuffer method has to return a type - an abstract, driver-indepentent type - and in Go, abstract types are interface types.

The foodriver Window is not expected to handle any Buffer implementations other than the foodriver Buffer implementation.

You will need to rethink your strategy. Your Editor should not be a Buffer. It should be able to render itself onto a Buffer (one provided by Screen.NewBuffer).

[gopherbot]

CL https://golang.org/cl/18791 mentions this issue.