From 51f0d11ee3a5cd7b31fcf575424e228d4e69eaa5 Mon Sep 17 00:00:00 2001 From: rubidium Date: Sun, 7 Jul 2013 10:37:16 +0000 Subject: (svn r25573) -Change: make content list appear faster by allowing some window redraws in between --- src/network/core/tcp_content.cpp | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'src/network') diff --git a/src/network/core/tcp_content.cpp b/src/network/core/tcp_content.cpp index 95b31fc9d..164f8de3c 100644 --- a/src/network/core/tcp_content.cpp +++ b/src/network/core/tcp_content.cpp @@ -192,8 +192,28 @@ bool NetworkContentSocketHandler::HandlePacket(Packet *p) */ void NetworkContentSocketHandler::ReceivePackets() { + /* + * We read only a few of the packets. This as receiving packets can be expensive + * due to the re-resolving of the parent/child relations and checking the toggle + * state of all bits. We cannot do this all in one go, as we want to show the + * user what we already received. Otherwise, it can take very long before any + * progress is shown to the end user that something has been received. + * It is also the case that we request extra content from the content server in + * case there is an unknown (in the content list) piece of content. These will + * come in after the main lists have been requested. As a result, we won't be + * getting everything reliably in one batch. Thus, we need to make subsequent + * updates in that case as well. + * + * As a result, we simple handle an arbitrary number of packets in one cycle, + * and let the rest be handled in subsequent cycles. These are ran, almost, + * immediately after this cycle so in speed it does not matter much, except + * that the user inferface will appear better responding. + * + * What arbitrary number to choose is the ultimate question though. + */ Packet *p; - while ((p = this->ReceivePacket()) != NULL) { + int i = 42; + while (--i != 0 && (p = this->ReceivePacket()) != NULL) { bool cont = this->HandlePacket(p); delete p; if (!cont) return; -- cgit v1.2.3-70-g09d2