I can also imagine its great to have FillTexture take a DynamicImage or even a GLuint (pointing to the texture in GL'istan).
Just like fonts, there are many different kinds of textures. We should have gelatin-picture use a texture strategy similar to the way it uses FontData. That way the implementation details (GLuint or DynamicImage) aren't leaked in the top level API. This TextureData should be implemented in gelatin-core.
I'm thinking something like
data TextureData = TextureData
{ textureShow :: String
, textureHash :: Int -> Int
, ...
}
And then have the backend provide a function that maps a texture to a TextureData. I'm not certain of what other functions would be needed in the TextureData record though.
As @cies said
Just like fonts, there are many different kinds of textures. We should have
gelatin-picture
use a texture strategy similar to the way it usesFontData
. That way the implementation details (GLuint or DynamicImage) aren't leaked in the top level API. ThisTextureData
should be implemented ingelatin-core
.I'm thinking something like
And then have the backend provide a function that maps a texture to a
TextureData
. I'm not certain of what other functions would be needed in theTextureData
record though.