Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2003:
[Freeciv-Dev] Re: gtk clients: translate_menu_path
Home

[Freeciv-Dev] Re: gtk clients: translate_menu_path

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: gtk clients: translate_menu_path
From: Jason Short <jshort@xxxxxxxxxxxxxx>
Date: Sat, 18 Oct 2003 13:46:56 -0400

--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




[Prev in Thread] Current Thread [Next in Thread]