A quick way to test if your framework has the problem is to write a simple stress test.
I have a render function in my map class that goes over the tile slots, if the current tile slot is inside the camera range, go through the list of tiles and check which ID it corresponds to and render the tileslot at x/y with the tiles sprite x/y. This render function is run inside the applications render function, when all the things in the program has been through the render function it blits it on to the screen.
Maybe my wording is poor. What i mean to say is that the maps rendering function blits the stuff on to the screen surface, later in the applications render function when everything in the program is blitted on to the screen surface i "flip" it.
Would be nice if you could reply to it so I know if I'm actually doing something wrong, which I don't think that I do.
I'm not sure about it, but it sounds like you are filling the screen with small tiles. In my mind, that means you have perhaps 30x20 background tiles + 50 or so foreground tiles + 50 or so UI sprites, totaling about 700 or so sprites. So load up and draw 1,000 sprites in a frame for one test and perhaps 2,000 or even 5,000 sprites in a frame in a second test, doing the same thing you do to normally draw them. Those can even be copies of the same image, if that is how you intend to run it. Run it and look at performance.
It is not uncommon that drawing a tile-based world in the way you described -- drawing the tiles individually -- has difficulty in running at a high frame rate. Many times (but certainly not always) the simple implementations will run into problems because they are copying the sprites to video memory every frame. Using SDL objects correctly probably won't have the problem. The test is to just make sure you are using them correctly and your solution will work.
Running a quick stress test can easily verify that your intended method can or cannot handle that many individual draw calls.
From what I can tell my program takes up 0% in the task manager with a 1000 tiles drawn inside and outside the screen region.
I go through my tilelist, blit the tiles and then when all are blit I send it from the buffer to the screen in one go.
I might go for splitting the map up in sections just because of speed anyway, might not be needed but might be a good thing anyway.