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: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Mon, 10 Jun 2002 11:21:25 +0200

On Mon, Jun 10, 2002 at 10:29:44AM +0200, Christian Knoke wrote:
> 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.

Speaking about the change and change all functionality of the city
report: the request are send seperate but with no delay between them.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "It is not yet possible to change operating system by writing
  to /proc/sys/kernel/ostype."              sysctl(2) man page


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