[Freeciv-Dev] Re: gtk clients: translate_menu_path

[Jason Short <jshort@xxxxxxxxxxxxxx>]

--On Saturday, October 18, 2003 5:41 PM +0100 Vasco Alexandre Da Silva 
Costa <vasc@xxxxxxxxxxxxxx> wrote:
> On Thu, 16 Oct 2003, Jason Short wrote:
> Well it is 98% as fast as it could be now. The heavy function is only
> run once at game startup instead of everytime the menus require some
> changing.
Great.

> The reason why I say is not the problem, is that the GTK+ 1.2 client has
> always used that heavy function. Albeit using strtok() instead of my
> special menu_path_tok() function, which should not be heavier than
> strtok().
But changes elsewhere in the GUI may (probably not, but maybe) have caused 
it to be called more often.
In gui-gtk-2.0, in 1.14 when we wanted to draw something to the screen we 
just copied the mapview backing store onto the mapview (GDK) window.
In HEAD, to do the same thing we call the dirty_rect() function which calls 
gdk_window_invalidate_rect() on the rectangle area that needs updating. 
Later when the screen actually needs to be updated (e.g., before animating) 
we do a flush by calling gdk_window_process_updates().  This function 
updates the window by flushing the necessary rectangles via 
map_canvas_expose (GDK may optimize this versus doing manual flushing, we 
hope) and also doing any other updates necessary (so menus and such should 
continue to work while animation is running).
There are three ways in which this could be slower.

1.  Extra overhead, just from calling GDK.

2.  map_canvas_expose is slower than it should be (I'm not sure if this is 
true or not).
3.  The extra GDK updates slow things down.

#3 is pretty much a given.  #1 should not be an issue if GDK is well 
implemented.  #2 may deserve some scrutiny (why do we refresh the overview 
every time the mapview is exposed?).
There are also advantages of doing it this way:

1.  It may be faster, since GDK may optimize updates (doing them in a batch 
or ignoring duplicates).
2.  It gives better window responsiveness (a direct correspondence to 
slowdown #3).
3.  It allows the SDL client (which really does need batch processing to 
avoid being really slow) to do flushes in this way.  E.g., the GUI 
interface is now set up so that flushes must be done in batches.
Naturally, #3 was the main impetus for writing the code in the first place. 
If the current implementation is slow (I don't know how to measure this), 
there are several other ways it could be implemented that shouldn't be any 
slower than it originally was.  However, I had expected the code to be 
faster this way...
> Also, that code is identical in S1_14 and it seems S1_14 is not as slow as
> HEAD. Or is it as slow as HEAD?
I can tell no difference.  But other people repeatedly complain that HEAD 
is slower, in gtk and gtk2 clients.
jason