[Commits] [wesnoth/wesnoth] 89192c: optimize minimap.cpp

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/wesnoth/wesnoth
  Commit: 89192cef823417c25cce1cd2f5e83993b320da7a
      https://github.com/wesnoth/wesnoth/commit/89192cef823417c25cce1cd2f5e83993b320da7a
  Author: gfgtdf <tischpapier at gmail.com>
  Date:   2014-03-29 (Sat, 29 Mar 2014)

  Changed paths:
    M src/minimap.cpp

  Log Message:
  -----------
  optimize minimap.cpp

moved 2 preferences::.. calls out of the loop so that we just call it once.

the following is especialy true on large maps, all results are recorded from a msvc 2010 release build, and recorded with the msvc 2010 sampling Profiler.

these calls are less expensive than the final scale_surface_sharp call at the end of the funcion. But if you assume the scale_surface_sharp woudn't be there, then they'd use a major part (~50%) of the cputime of get_minimap.

i also tested replacing scale_surface_sharp at the end of the function with scale_surface. Here are the results:
tested on LotI Mp Map (part of LotI addon) which has a size 200x200 with fog but no shroud, no logs, ingame debug mode enabled (the :debug wesnoth-console command).
the image on the upper middle is made with scale_surface the other two are made with scale_surface_sharp.
The down-left Image are the profiler results from the scale_surface version of get_minimap, the down-right are from the scale_surface_sharp version. The record was started shortly before a moving so the record only  shows the cputime during moving. Also the content of this commit is used in those testings.
http://i.imgur.com/YETVuNq.png
the profiler shows that during movements (with fog) more than 50% of the cputime of wesnoth is spend in scale_surface_sharp for get_minimap, and i personaly think differences in the minimap are not worth that. But there are different opinions and thats why i didn't change it yet, but i still propose replacing the last call

minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));

with something like: 

if(map.w() > 100 || map.h() > 100)
{
minimap = scale_surface(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
else
{
minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
note, that the 100 is choosen rather randomly.
If that's a problem with msvc then i propose wrapping it in a #if.
I have heared that we will be able to do scaling with hardware acceleration later (around september), but i don't see how thats a reason to not do this until then.