Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2002:
[Freeciv-Dev] Re: [Patch] Making city report list faster
Home

[Freeciv-Dev] Re: [Patch] Making city report list faster

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Cc: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Making city report list faster
From: Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 10 Jun 2002 03:47:10 -0400

Raimar Falke wrote:
This patch should avoid make the city report dialog a bit faster.

Does this really do what it looks like it does? <checks> That's a *great* improvement to something that has always bugged me (since it seems so fixable). In a test, it reduced the lag in a large-scale change of city production by 50% (4 seconds to 2).

I think in the future an even better solution to this problem is possible.

Problem: when you change stuff on the client, it has to "request" the change from the server; the change usually doesn't even happen until the server responds confirming the change. Thus when the user makes a change in the GUI, all that really happens is we call some function to send a message to the server. When the server sends a response, it updates whatever-it-is-we're-talking-about and the client/GUI make the actual change.

This is a particular problem when talking about the city report dialog. In theory this dialog can be used to easily control massive number of cities, but anyone who has tried to do this quickly realizes that it is actually pretty slow. The main reason for this is that when you change a bunch of cities, a bunch of change requests get sent to the server and the update confirmations come in one-at-a-time - and are all handled individually. Thus the update takes a really long time to draw.

This patch fixes the second problem: when you change something in the city report, the report is "frozen" until the last change is confirmed. Thus (to take an extreme, but possible example) if you change 100 cities all at once, instead of having 100 graphical updates there will just be one (this is important since graphical updates are quite slow). (It looks like it does this by monitoring the request ID, which is a direct result of work for the CMA. This is also a bit of a hack, and probably a bit unstable in the long term as well.)


However, there is still lag: the change cannot be made until the last packet from the server is received. I think there is a better, and more general solution that is possible. When a change is made by the user in the GUI, the client should change that data internally _as well as_ send the request to the server. When the server responds, the client again updates. If the change was approved, everything is easy and no action is needed. If the change was not approved, it must be reverted at the client end. This has the benefit that it will reduce the lag to nearly nothing in almost all cases; the effect will be especially noticable on a machine with a slow connection. In a few cases (when the change is not approved) the user may get behavior that is slightly odd-looking.

There are several drawbacks of such a system. One, the behavior when a change is rejected by the server will be a bit chaotic: the user will see the data changed and then reverted. Two, the data packet sent to the client will have to be changed so that when a change is made (whether it is accepted or rejected) the server needs to send the full new state. For instance, if the state is rejected the server needs to tell the client what the state was before the change was made (i.e. what it should be). But it will still be necessary to tell the client what the state was if the change is accepted (consider the case where two changes are made before the server responds: the first is accepted and the second rejected).

But the advantages quite outweigh these disadvantages, IMO. First, as I've said the update latency is dropped to nearly zero (you never have to wait on a network connection). Second, the system itself is both more elegant and more stable. It can be used for any update made client-side (in fact, I'd say everything should be changed to keep things consistent). In this particular case, rather than having to have common (rather deep) code to "freeze" and "unfreeze" the city report along with tracking the ID of the last packet request, we can just leave it up to the GUI to "freeze" the list (aka GtkCList) before requesting all of the changes and "unfreeze" it afterwards (at which point all the changes will have been made). Although the updates will still be done asynchronously (we still rely on the server to send us data about the validity of the change, and we don't block waiting for it), from the GUI code's point of view it is being made synchronously (the change is made during the call which requested it).

Has such a thing been discussed before?

jason



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