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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Mon, Jun 10, 2002 at 03:47:10AM -0400, Jason Short wrote:
> 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.

I want to point out that this is incorrect. The server will always
send a PACKET_PROCESSING_STARTED packet before and a
PACKET_PROCESSING_FINISHED packet after the actual packets caused by
this request. There is no exception. These packets allows you to
group individual commands as the patch does.

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

Nice idea but there are problems. For example there are GUI changes
which are rather hard to undo for the user:
 - change via the city report and the client print "Production changed
 in London from foo to bar." But no the server rejects this
 change. What should happen? Add a "Well ... take this back London
 still produces foo."? Seems odd.
 - founding a new city: the user press 'b' and press return to accept
 the city name. The new city dialog pops up. The user changes the CMA
 settings. And POP the server decides that the city isn't allowed at
 this location. Very odd if you than pop the city dialog down and
 remove the city from the map.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  reality.sys corrupt. Reboot Universe? (y,n,q)