From 89192cef823417c25cce1cd2f5e83993b320da7a Mon Sep 17 00:00:00 2001 From: gfgtdf Date: Sat, 29 Mar 2014 21:16:42 +0100 Subject: [PATCH] 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(minimap->w * ratio), static_cast(minimap->h * ratio)); with something like: if(map.w() > 100 || map.h() > 100) { minimap = scale_surface(minimap, static_cast(minimap->w * ratio), static_cast(minimap->h * ratio)); } else { minimap = scale_surface_sharp(minimap, static_cast(minimap->w * ratio), static_cast(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. --- src/minimap.cpp | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/minimap.cpp b/src/minimap.cpp index befdb54ad64..8cf56ed8bf3 100644 --- a/src/minimap.cpp +++ b/src/minimap.cpp @@ -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);