You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers. No questions about C++ programming or topics which are answered in the tutorials!
FrameImagePtr = static_cast<s32*>(FrameImage->lock ());
TexturePtr = static_cast<s32*>(Texture->lock ());
memcpy(TexturePtr, FrameImagePtr, FrameImage->getImageDataSizeInBytes());
// unlock de texture and the image
Texture->unlock();
FrameImage->unlock();
When I migrate my code from the shader-pipeline branch to the trunk, I got a huge performance overhead on ITexture::lock (essentially COpenGLCoreTexture::Lock() I found out this using a profiling tool in visual studio 2015.). When I playing two 1080p videos in the shader-pipeline branch, my application framerate can easily reach more than 300fps. Using the same setup, the framerate drops under 10fps in the trunk. Did I do something wrong here to copy the image to the mesh texture?
In shader-pipeline original IImage data is stored inside ITexture (doubled memory for textures! so it was unacceptable) thats why ITexture::lock is really fast. In trunk we have to download IImage from GPU and convert them from RGBA to proper color format on CPU side. Anyway if you need an old solution (doubled memory, but fast ITexture::lock) in trunk for some texture you can use ETCF_ALLOW_MEMORY_COPY flag, anyway it looks like your problem may be solved in the other way... please check a following modifications:
FrameImagePtr = static_cast<s32*>(FrameImage->getData()); // IImage::lock is deprecated
TexturePtr = static_cast<s32*>(Texture->lock(ETLM_WRITE_ONLY)); // the most important change, you don't need to download a data from a GPU, just upload to them.
memcpy(TexturePtr, FrameImagePtr, FrameImage->getImageDataSizeInBytes());
// unlock for IImage is deprecated, so unlock only ITexture
Texture->unlock();