BurntSushi
commented
12 years ago I am still not quite sure what the best way to solve this is. From my perspective, there are two possible solutions. Both have some serious trade offs. If I'm missing another way, I'd love some input.
First, here's a brief description of the problem so that I don't alienate anyone not privy to how X image formats work. In essence, the configuration of any particular X server specifies the byte order, depth, bits per pixel and scanline units (for bitmaps only) for images stored on the server. This means that when you send an image to X for it to be displayed, it must be in the format specified by the configuration of X. In general, there is a very common configuration available in most X servers these days: LSB byte order, 24 bit depth and 32 bits per pixel. These values are assumed by the xgraphics package currently, and it only works because they are common.
But as evidenced by the Raspberry Pi, there are times when that configuration is not available.
So we have two options.
Option 1: Encapsulate the details of how an image is stored in a single Image type
The Image type here would satisfy Go's standard image.Image interface, and thus could be used with other image drawing packages. The benefit here is that sending images to X is super fast, since the image is already in the correct format. The con here, though, is that other image drawing routines will very likely have to fall back on using an interface to manipulate the image, which is slow. Very slow.
Option 2: Convert values of type image.Image to the appropriate X format on-the-fly
This is the more flexible solution, in that any image could be sent to X that implements the image.Image interface. We could even code fast paths for common image formats (like we are already doing) like *image.RGBA. The problem is that this incurs a heavy cost: image conversion must be done every time an image is sent to X.
I suspect that I will be forced into choosing option 2. The reason is that option 1 pretty much requires that a rendering library be built that can manipulate these special types of images efficiently. This is something I just don't have the time or expertise to pull off.
But, I also don't want to go down a path that has insurmountable performance penalties.
I will provide benchmarks before going forward.
The xgraphics package assumed the following configuration options of an X server:
Some or all of these configuration options aren't available (or aren't well supported) on the Raspberry Pi. More generally, the xgraphics package should be able to support some reasonable subset of these configuration options.