Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 28, 2005, at 10:06 AM, Dan Potter wrote:
>
> If that's true, I think the ARGB8888 data is totally unnecessary. A  
> good first step might be to free that up as soon as it's loaded  
> with GL.
>

This is the current allocations that I can spot in the code:
Texture::loadFromFile(...):
   m_ptr contains the "raw" image data
   m_txrdata contains the ARGB8888 data used in the glTexImage2D call

m_ptr can equal m_txrdata if the image file is in ARGB8888 format.   
If not, m_ptr is allocated and the "raw" image data is memcpy into  
it.  Ideally this can be avoided by moving "img" from being a method  
variable to a class member variable and then m_ptr can be destroyed  
(maybe).

Here is what I suggest :)

1) Take current Texture class and rename it to DynamicTexture and  
remove the support for loading image files.  This in effect would  
become the "palette" based Texture class.
2) Create a new ImageTexture class that supports only loading from a  
file.  Remove support for getPtr(), canvasLock(), canvasUnlock().
3) Move "common" bits to a new pure virtual Texture class so we can  
still bind a Texture to Banner, etc.  Using a pure virtual class  
would be good in this case since it can be treated as an "interface"  
of sorts rather than a normal class.  However, a normal class which  
we extend to add "extra" functionality would also work, similar to  
Object.

>
> Keep in mind too that the DC has hardware paletted texture support.  
> So there might be something clever to be done there too.

True, the DC does have paletted textures, but IIRC the texture data  
must be twiddled so we will need to keep that in mind as well.

Mike