Opengl will be slower than sdl on computers with either bad graphics cards or bad graphics drivers, but in general it is much much faster. On the order of 10 times faster or more for some things. But you have to code the opengl way, and not the sdl way.
Directly modifying pixels in a texture is going to be slower than blitting pixels to the screen, so you will want to use another interface to draw pixels to a texture and then replace the texture for it to be update on the screen. If you can find a way to accomplish what you want without changing or editing textures, it will probably work a bit better. On more advanced cards you can use pixel rendering functions to offset this issue, but that is less portable. Another common slowdown with using opengl for 2d is badly sized textures. Most cards will either have graphical errors or run slowly if any texture is not a power of 2 in size (256x256, 512x512 etc). This is not much of a problem, since you can use scaling of polygons rather than scaling of a textures pixels in order to make anything look the right size on screen. Finally, polygon count does matter. If you use tiles and make a giant map, say, 10,000 x 10,000, and then blit that whole map to the screen, it will run incredibly slow. You have to be just as careful in opengl on how much data you pass to the renderer as you would have to watch the number and size of your blits in sdl. Lastly, display lists or other batch techniques to limit the amount of functions python has to call are a must. Python function calls are slow, so if you are telling opengl to draw each vertex of the entire scene every frame, it could possibly be slower than the blits would just due to the python overhead. I'd like to see what your test was that ran slower in opengl than sdl. Everything I've done has ran 100-300 fps in opengl versus 40-60fps being about the max I've EVER seen SDL run anything.
