Follow-up Comment #3, patch #3550 (project freeciv):
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.
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?3550>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
