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]
To: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Making city report list faster
From: Christian Knoke <chrisk@xxxxxxxx>
Date: Mon, 10 Jun 2002 10:29:44 +0200

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

In a real game, this situation is not as rare, because you play against
the clock. Your changes may, or may not receive the server in time, that
is, before the server's switch to the next turn. So, the reverts will
happen quite often.

I won't comment on your proposal because IANAC, but I have another idea:
Is it possible to send all requests to the server in a bunch, not one
by one? Or is it this way right now? I could imagine this would eliminate
the lag nearly as well.

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.


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