0ct0pu5/wesnoth
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

optimize minimap.cpp

Browse source 
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.
This commit is contained in:
gfgtdf 2014-03-29 21:16:42 +01:00
parent 6b9ee774ec
commit 89192cef82
1 changed files with 5 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
src/minimap.cpp
View file

@ -46,6 +46,9 @@ surface getMinimap(int w, int h, const gamemap &map, const team *vw, const std::
DBG_DP << "creating minimap " << int(map.w()*scale*0.75) << "," << map.h()*scale << "\n";
bool preferences_minimap_draw_terrain = preferences::minimap_draw_terrain();
bool preferences_minimap_terrain_coding = preferences::minimap_terrain_coding();
const size_t map_width = map.w()*scale*3/4;
const size_t map_height = map.h()*scale;
if(map_width == 0 || map_height == 0) {
@ -90,9 +93,9 @@ surface getMinimap(int w, int h, const gamemap &map, const team *vw, const std::
, 0
, 0);
if (preferences::minimap_draw_terrain()) {
if (preferences_minimap_draw_terrain) {
if (!preferences::minimap_terrain_coding()) {
if (!preferences_minimap_terrain_coding) {
surface surf(NULL);