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

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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