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

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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 think in a timed game this would be more than made up for by the speed 
with with most changes could be made.
> 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.
It would not reduce the *network-related* latency, since you would still 
have to wait for the network to respond to a change before updating 
anything (assuming you don't also do "lazy writing", as Per calls it).
It could reduce the *GUI-related* latency because it allows you to 
easily wait to update the graphics until you have the full packet. 
However Raimar's patch does essentially the same thing, although it is 
(very slightly) uglier since it needs to statically remember the packet 
request ID.  (Assuming I understand things correctly, which I may not...)
jason