Maybe i should explain the problem a little better.

I create a surface and load a bitmap onto it then i copy this to the backbuffer and render it to the screen. i am loading 1 640*480 bitmap so i cant see why it goes so slow well upto 4 parts of the same Bitmap at the most. i am getting about 4 frames a second in windowed or fullscreen. i had another example i made using most of the code but it used the CSprite stuff instead of the CLayer stuff and that ran at a decent sort of speed.

so if you can see any problems in the CLayer code please let me know thanks again

It's not the loading of the bitmap that is slow it is the copy back from VRAm that is slow, the GPU has to flush it's command buffer before each copy can be done. Generally speaking you need to avoid copying texture from the GPU back to system Ram.  CSprite is faster because at most it only does one copy each frame your layer is doing 2-4 copies, if you know you need to update two areas in the texture just lock the whole thing and then update both areas before unlocking the surface, this means only one copy. LockRect is the function that causes the copy from GPU to CPU memory btw.

If you can get away with rendering a quad with a texture to a render target it will be alot faster.If you can get away with rendering a quad with a texture to a render target it will be alot faster. Also split that header up into smaller files or post only the relevant pieces of code please.

Maybe i should explain the problem a little better.

I create a surface and load a bitmap onto it then i copy this to the backbuffer and render it to the screen. i am loading 1 640*480 bitmap so i cant see why it goes so slow well upto 4 parts of the same Bitmap at the most. i am getting about 4 frames a second in windowed or fullscreen. i had another example i made using most of the code but it used the CSprite stuff instead of the CLayer stuff and that ran at a decent sort of speed.

so if you can see any problems in the CLayer code please let me know thanks again

It's not the loading of the bitmap that is slow it is the copy back from VRAm that is slow, the GPU has to flush it's command buffer before each copy can be done. Generally speaking you need to avoid copying texture from the GPU back to system Ram.  CSprite is faster because at most it only does one copy each frame your layer is doing 2-4 copies, if you know you need to update two areas in the texture just lock the whole thing and then update both areas before unlocking the surface, this means only one copy. LockRect is the function that causes the copy from GPU to CPU memory btw.

If you can get away with rendering a quad with a texture to a render target it will be alot faster.If you can get away with rendering a quad with a texture to a render target it will be alot faster.

Maybe i should explain the problem a little better.

I create a surface and load a bitmap onto it then i copy this to the backbuffer and render it to the screen. i am loading 1 640*480 bitmap so i cant see why it goes so slow well upto 4 parts of the same Bitmap at the most. i am getting about 4 frames a second in windowed or fullscreen. i had another example i made using most of the code but it used the CSprite stuff instead of the CLayer stuff and that ran at a decent sort of speed.

so if you can see any problems in the CLayer code please let me know thanks again

It's not the loading of the bitmap that is slow it is the copy back from VRAm that is slow, the GPU has to flush it's command buffer before each copy can be done. Generally speaking you need to avoid copying texture from the GPU back to system Ram.  CSprite is faster because at most it only does one copy each frame your layer is doing 2-4 copies, if you know you need to update two areas in the texture just lock the whole thing and then update both areas before unlocking the surface, this means only one copy.

If you can get away with rendering a quad with a texture to a render target it will be alot faster.If you can get away with rendering a quad with a texture to a render target it will be alot faster.