A new opengl texture should be allocated in the copy constructor and assignment operator for ofTexture(). Otherwise the opengl texture will be shared by future copies. The problem crops up when for example a copied ofTexture goes out of scope and deletes the shared opengl texture.
Put this code at the end of the draw() in the textureExample app:
texColor2 = texColor;
The texColor texture will be drawn on the first frame, and then both texColor and texColor2 will not be displayed in subsequent frames as the opengl texture has been deleted when texColor2 goes out of scope.
the problem is how to copy the content of the texture to the new one. the simplest way would be to download the data from the graphics card memory to the computer one and then re-upload again to the new texture which will be really slow. the other way seems to be using an fbo which is kind of complex and perhaps not supported by some old hardware.
perhaps we can just have a flag in case a texture is created by copy so when it’s deleted it doesn’t destroy the original data? any other way of copying a texture data?
I think probably go the slow way. Isn’t this what ofImage does anyway?
People can use FBOs if they then want speed.
Or disable the copy/assignment constructors for ofTextures…because I think the current situation is confusing as it’s not a true copy.
What is the current status of this? In my application I have processing happening at two different rates, slowly in the thread and rendering speed in my main application. My thread (slowly) renders to an FBO, and then I would like to render transitions. This means I need a true copy of my FBO, so I can fade between the content corresponding to the FBO in the previous thread iteration and the current FBO just rendered by the thread.
all objects in the GL folder make a shallow copy, that is the copy is actually a reference to the original. if you want to make a real copy of a texture the easiest is to use an fbo to blit the original to a new copy