Non GL Renderers

[NickHardeman]

GL based classes like ofTexture have become integrated into the OF core. Since it is GL based, implementing non-GL based renderers proves difficult. Especially for commonly used classes like ofTrueTypeFont, ofVideoPlayer, ofVideoGrabber, etc. that rely on ofTexture.

Adopting a BaseClass, implementation structure similar to ofVideoGrabber or ofAppBaseWindow would allow for class abstraction and access to the underlying backend texture type. The current public class keeps its existing signature. Possibly deprecating very specific GL functions to begin phasing them out.
For example.

ofTexture {
#if defined( OF_DAWN ) 
	ofTextureWebGpu& getTextureWebGpu();
#endif
#if defined( OF_OPENGL ) || defined( OF_OPENGL_ES) 
	ofTextureGL& getTextureGL();
#endif

— or —
// same as ofVideoGrabber. 
template<typename TextureType>
std::shared_ptr<TextureType> getTexture(){
	return std::dynamic_pointer_cast<TextureType>(getTexture());
}

}

Should the texture types be set by a define or by the renderer that is created by the window? Defines would make it clear what is used and may allow for faster compiles. Texture type by the renderer would allow for a bit more flexibility.

GL specific calls could be abstracted, similar to the current ofTexCompression enum.

enum ofTexCompression {
	OF_COMPRESS_NONE,	///< No compression.
	OF_COMPRESS_SRGB,	///< sRGB compression.
	OF_COMPRESS_ARB	///< ARB compression.
};

For backwards compatibility, functions that take in GL specific arguments like GL_RGB, GL_RGBA, etc. could have an enum that maps to their GL counterparts. Some defines may be necessary for ES specific or missing types.

enum ofTextureFormat : int {
    OF_TEXTURE_FORMAT_UNKNOWN         = 0,

    // unsized (legacy GL_RGB etc.)
    OF_TEXTURE_FORMAT_ALPHA           = 0x1906, 
    OF_TEXTURE_FORMAT_RGB             = 0x1907,
    OF_TEXTURE_FORMAT_RGBA            = 0x1908,
    OF_TEXTURE_FORMAT_LUMINANCE       = 0x1909,
    OF_TEXTURE_FORMAT_LUMINANCE_ALPHA = 0x190A,
    OF_TEXTURE_FORMAT_DEPTH           = 0x1902,

    // sized
    OF_TEXTURE_FORMAT_R8              = 0x8229,
    OF_TEXTURE_FORMAT_RG8             = 0x822B,
    OF_TEXTURE_FORMAT_RGB8            = 0x8051,
    OF_TEXTURE_FORMAT_RGBA8           = 0x8058,
    OF_TEXTURE_FORMAT_RGB16F          = 0x881B,
    OF_TEXTURE_FORMAT_RGBA16F         = 0x881A,
    OF_TEXTURE_FORMAT_RGB32F          = 0x8815,
    OF_TEXTURE_FORMAT_RGBA32F         = 0x8814,
    OF_TEXTURE_FORMAT_DEPTH24         = 0x81A6,
    OF_TEXTURE_FORMAT_DEPTH32F        = 0x8CAC,
    ….
};

So functions like allocate() would not break in existing projects.
void allocate(int w, int h, int glInternalFormat, bool bUseARBExtension);

And would also have an enum counterpart
void allocate(int w, int h, ofTextureFormat fmt, bool bUseARB);

Advanced use cases where ofTextureData is accessed and set by users directly proves a bit more difficult.

Other GL based classes could adopt the same approach, ofFbo, ofShader, ofVbo, ofBufferObject, ofCubeMap, ofShadow, etc.
The goal being to transition away from GL dependent code while also supporting as many current code bases as possible.

Curious what the community thinks about approaches that allow for the inclusion of non-GL renderers.

[ofTheo]

ofTexture {
#if defined( OF_DAWN ) 
	ofTextureWebGpu& getTextureWebGpu();
#endif
#if defined( OF_OPENGL ) || defined( OF_OPENGL_ES) 
	ofTextureGL& getTextureGL();
#endif

— or —
// same as ofVideoGrabber. 
template<typename TextureType>
std::shared_ptr<TextureType> getTexture(){
	return std::dynamic_pointer_cast<TextureType>(getTexture());
}

}

Yeah!! I think this choice is the big one to figure out.
I think I like the second option because it's more consistent with the other base types and it keeps the function names the same but curious if there is a downside to going that way.