[SDL] Follow up (more details, test results, replies)

[Leon Marrick]

     One of the things I didn't do in the original post (mostly for brevity) 
is to give some more details on the "background story" to this post.  I should 
have at least included this information in the readme, because several posts 
in this thread offer solutions that, however elegant, don't help my problem.

     For starters, I didn't explain why using OpenGL is flat out for my 
project.  OpenGL is a large, complex graphics library that virtually everyone 
likely to modify my code is 1) not going to have, 2) not going to know much 
about, and 3) not going to spend the considerable amount of time needed to set 
up and understand unless no other alternative exists.  Because multiple 
alternatives /do/ exist, discussion of OpenGL has no bearing.
     I ask people who post OpenGL solutions on this - not an OpenGL mailing 
list - to remember why a lot of us come to SDL.  Not to find a wrapper around 
any other library, but to find a Simple, Direct, Multimedia library that we 
hope will be a complete (or nearly complete) solution for most simple cross-
platform 2D projects, thus freeing us from having to juggle any other library.

     SDL isn't a complete solution for me and my project.  The major reason is 
speed.  To attain anything close to the performance of the several single-
platform ports of my project (Mac, X11, and Win32 being three), I must solve 
at least one of two problems:  Get text onto the application SDL surface 
faster, or figure out why SDL_Update_Rects is so bloody slow on all tested 
machines and using all tested drivers.

     The source provided makes it easy to determine what problem is more 
important.  Or not, as you will see below.


Kein-Hong Man,

     Thank you very much for your tests of the supplied code.  Your setup 
instructions for each test are perfectly clear, but I'm astonished at your 
results.  In particular, your results show a much larger proportion of time 
spent in update_rects than mine do.  Here are mine:


=======================================

Test results, with source as supplied (no changes to code, 64 stored update 
rects)

Compiled with Visual C++ (optimized for speed).  Using SDL 1.2.11.

On a 2.2 Ghz desktop machine running windows XP, Pentium IV, Radeon 8500 video 
card, 32-bit display:

Time needed to display text pages: 3971.
     - spent in text output: 1454
     - spent in screen refreshes: 2511
     - spent in miscellaneous: 6

Time needed to display text lines: 2684.
     - spent in text output: 1225
     - spent in screen refreshes: 1447
     - spent in miscellaneous: 12

Time needed to display individual characters: 4571.
     - spent in text output: 1670
     - spent in screen refreshes: 2784
     - spent in miscellaneous: 117


On a 633 Mhz desktop machine running Windows 98, Celeron, no seperate video 
card, 16-bit display:

Time needed to display text pages: 12268.
     - spent in text output: 4985
     - spent in screen refreshes: 7033
     - spent in miscellaneous: 250

Time needed to display text lines: 13793.
     - spent in text output: 4530
     - spent in screen refreshes: 8830
     - spent in miscellaneous: 433

Time needed to display individual characters: 22978.
     - spent in text output: 7543
     - spent in screen refreshes: 13170
     - spent in miscellaneous: 2265

======================================

     My earlier code (the version before the present one) worked much the same 
way as Kein-Hong Man describes:  Render each character in the current font to 
an individual 8-bit SDL surface, use SDL_SRCCOLORKEY and SDL_RLEACCEL for 
speed, and use palette edits to enable the many text colors needed.
      Text output results for that method were almost twice as slow when the 
application was run in 8-bit mode (256 colors), and quite a lot worse when it 
was run in any other color depth.  As you can see from the above results, a 
doubling of the time needed to output text has a significant effect on total 
performance on my test machines.  
    These results pass the "Is it reasonable?" test.  After all, when you turn 
a font into graphics and also insist upon blitting from 8-bit surfaces to non-
8-bit surfaces, you can expect things to be slow.

     When I replaced the pre-rendered blitting code with the current pixel 
offset code, my SDL app went from "it hurts my eyes it flickers so much" 
to "just barely acceptable ... on fast machines".  If this improvement hadn't 
happened, I might not have offered an SDL version at all.

     Maestros, gurus, experts, and cognoscenti:  I claim SDL (UpdateRects in 
particular) is slow, especially on Windows, but also on Linux.  The obvious 
response to such a claim is "no, /the way you use SDL/ is slow".  Well, I've 
tried the example code, followed the tutorials, read the docs and this mailing 
list, scoured the web for ideas, tried out all the drivers listed, optimized 
for weeks on end, used four different compilers (bcc, msvc, dev-c++, gcc under 
Konsole), and STILL HAVEN'T GOTTEN ANYTHING LIKE THE SPEED OF X11, MAC, or 
WIN32!!

Sorry for yelling.  It's just that I am /so/ frustrated.  I don't pretend to 
be an expert.  Any help or ideas are much appreciated.