Explore a more extendable graphics API architecture

Summary

This RFC proposes an extension to the API implemented in #90 (closed) to allow extendability to other graphics APIs in the future.

Motivation

#90 (closed): Implemented the first iteration of an API that supports both OpenGL and OpenGL ES, this was done by pulling out common code and specializing small functions containing OpenGL calls. This works well for now, but might not be the best idea going forward as it might not fit other APIs we might want to implement in the future for compatibility reasons.

#99 (closed): Proposes a tighter API that resembles OpenGL's API, it also aims to group code such that all the code of a specific API is contained within one class. This also works well, but would be bound even more to OpenGL, so extending splash with support for Vulkan, WebGPU, or another API might require more work.

Proposal

This RFC proposes an extension to the changes implemented in #90 (closed), where graphics related classes such as Texture_Image would be devoid of API specific details even more compared to the current implementation. This could be implemented by defining a higher level interface for the needed operations that would then be defined at a lower level by each API's implementation.

Let's take Texture_Image as an example. It mostly acts as a link between OpenGL textures and Splash's images, it provides a few operations that are applied on OpenGL textures, and a few other utility functions for creation and reading.

The changes proposed here would for example pull all API specific details into an inner class, and only expose a few high level calls that would call into the specific APIs.

So the final class could look something like:

namespace Splash {
class Texture_Image: public Texture {

public:
    std::shared_ptr<Image> read();
    ImageBuffer grabMipmap(unsigned int level = 0) const;
    RgbValue getMeanValue() const;
    // etc..

private:
    // Points to an OpenGL/GLES/Vulkan implementation
    std::unique_ptr<gfx::Texture_ImageImpl> impl
};

}

Impact on already existing code

The changes mentioned here will add an extra layer of code, but will allow greater separation of concerns and hopefully better extendability to other APIs that don't quite fit OpenGL's model.

Roadmap

(Enumerate here the steps required to achieve the work.) TODO

More details

(Provide here more details if any.) TODO