HW vs SW blitting

[Cyphre]

Hello to all on the forum,

My aim is to achieve fastest blitting under Windows.
I'm using software rendering engine for hi-quality 2D antialiased vectorial GUI(as I need pixel-perfect crossplatform output). So far I have been using StretchBlt() WinAPI function to blit either the whole framebuffer or some part of it on the screen.
Recently I have read that it is possible to achieve faster HW accelerated blitting using OpenGL texture surface so I tried to write simple test which uses glBindTexture() and glTexImage2D()/glTexSubImage2D() OpenGL calls and then maps the texture on some quad shape.
It worked fast in case I have SW generated the texture bitmap once and load it to the GFX card memory (using the glBindTexture()). Unfortunately the framerate went rapidly down when I wanted to change content of the texture bitmap in every frame (probably due the CPU-MEM<->GPU-MEM transfer) so I guess in my case the HW blitting has no reason as it is fast only for games when you load all your textures into the GFX memory first. Or am I wrong?

To make my case clear. I need to:
1.SW render into framebuffer
2.blit as fast as possible into the window.
in every frame

Is there any way how to change content of the OpenGL texture directly at pixel level without the need to re-load it from CPU-MEM to GFX-MEM? Any other ideas how to solve this most efficiently?

[Nick]

Writing to video memory is fast, but reading is slow (which you need for transparancy and such). So the solution is to do your software rendering entirely in system memory, copy the result to video memory, and then let hardware blit it.

[Cyphre]

Writing to video memory is fast, but reading is slow (which you need for transparancy and such). So the solution is to do your software rendering entirely in system memory, copy the result to video memory, and then let hardware blit it.

Thanks for your reply. Yes, I think that is what I'm doing. The question is still which method is the fastest for the last step? Should I use OpenGL/DirectX or rather stay with WinAPI GDI based blitting(as this should be also HW accelerated)?
Another question is if the copy to video memory is not the bottleneck(at least my opengl test showed me it is significantly slower on my machine than WinAPI blitting) and which method do this the fastest way?

[Cyphre]

I should also note that I'd like that my app is running on wide range of Windows PC setups with decent performance and it is not limited to some hi-end gfx cards.

[Skavenger]

I don't see why you need to SW render to an OpenGL texture. Wouldn't it just be faster to have your sprites/tiles/etc as textures and then use OpenGL to "Render" those to the framebuffer?

[Cyphre]

I don't see why you need to SW render to an OpenGL texture. Wouldn't it just be faster to have your sprites/tiles/etc as textures and then use OpenGL to "Render" those to the framebuffer?

Yes, it would be faster but I need to dynamically change the 'content' of the texture. In my case I'm not blitting static gfx but dynamic SW rendered GUI content which can be changed either by user or programatically in every frame.

Imagine that the texture contain screen of your desktop for example. Or another example from game scenario: game is using realtime procedural textures...

So basically I'm trying to create dynamic virtual window content mapped on texture surface. The question still remains how to 'update' the texture content as fast as possible?

[Nick]

The question is still which method is the fastest for the last step? Should I use OpenGL/DirectX or rather stay with WinAPI GDI based blitting(as this should be also HW accelerated)?
On Windows the fastest way would be to use DirectDraw.
Another question is if the copy to video memory is not the bottleneck(at least my opengl test showed me it is significantly slower on my machine than WinAPI blitting) and which method do this the fastest way?
Don't use a C loop to copy the pixels. A reasonably fast option is memcpy. But even faster is to use MMX or SSE.

[Cyphre]

On Windows the fastest way would be to use DirectDraw.

Don't use a C loop to copy the pixels. A reasonably fast option is memcpy. But even faster is to use MMX or SSE.

Thanks for the suggestions. I'll give it a try.