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

[Christian Knoke <chrisk@xxxxxxxx>]

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

This is probably true. But my point is, that many reverts will confuse
the player much.

> 
> >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).

Hhm, the network latency is about 0.5 to 1.0 seconds, while the latency
I actually encouter is 15 to 30 seconds ...

> 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...)

I'm going to try Raimers patches now.

Christian

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