Made a minor thinko in file #16747 - corrected now.

(file #16752)

Well, it seems we don't quite understand each other, but OK.
I went with the extreme duplication instead.
You'll see what I mean once I'll attach updated version of both patches.

In case of update_rect_at_mouse_pos, the problem comes down to a simple thing - the function signature is 'void update_rect_at_mouse_pos(void)'.
The already stated reason comes into play, the same one I was against gdk_display_get_device_manager 'solution' in the patch in bug #20097 - the event knows exactly where mouse is when the event happened, gdk_display_get_device_manager says only where the mouse is while the function runs.

While usually those positions (due to human reaction speed vs cpu power) are very close, that still means the code would be wrong.
So, with such signature, there's no reasonable way to pass the coordinates from the event handler to this function.

create_line_at_mouse_pos is a different case: as I said in the comment of that patch, the only reasonable usecase is already handled elsewhere in the code, that is the lines are effectively drawn twice now - once by create_line_at_mouse_pos, the second time by move_{map,overview}canvas - therefore non-empty create_line_at_mouse_pos is redundant...well, at least AFAICT.

Well, perhaps cur_x/cur_y could be used here instead of trying to query the pointer, but all those global vars make me cringe.
I need to think about it.

On a surprisingly related note: that cpu usage jump when a selected unit is on screen (due to that animated circle) is quite annoying.

Well, TBH, there's one major catch here: while things work as-is both in gtk2 and gtk3 clients, technically they only do that due to luck.

Even back in gtk2 its devs stressed that all of the drawing should be done in 'expose-event' handler. It's still the same for gtk3 and 'draw'. The way update_rect_at_mouse_pos() works (well, more exactly update_selection_rectangle(x, y)), regardless of whether it's merged or not, already pushes it.

But I don't see any way of implementing this without a major rewrite of not only the client, but probably common code too.

I've merged it, cause while due to human reaction time, doing it like city_activated_callback (cityrep.c) and impr_callback (citydlg.c) do (which I didn't touched and already explained why it's IMHO unfixably broken) would seem to work, it's the most natural place with access to the required data, but at the same time, that data can't be as reliably retrieved anywhere else.