Axel Dörfler wrote: > Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote: > >>>it would need to be something more like GetMouse() or even >>>should call DoUpdate() directly. >> >> I'm still not sure about this method. What I think it should do, is >>process the _UPDATE_ request that is pending in the message queue, >>just >>as GetMouse() does, and above that, it should query the server if >>there >>still are invalid regions to be updated (regions that became invalid >>since the server sent the last _UPDATE_ request) and if there are do, >>get the data from the reply and do a DispatchMessage(updateMsg, this) >>again. >> That is a bit complicated to achieve, so I think we should stick >>with >>the UpdateIfNeeded() you implemented, and if problems appear, >>consider >>the above. > > That sounds very strange to me: isn't that just a work-around for the > awareness that the "one _UPDATE_ at a time" method is not sufficient? Nope. Once we are done processing the _UPDATE_ request, if there is something that still needs to be redrawn (another window passed above ours) the server will send another _UPDATE_ request. Now, we can't stay and wait for this 2nd update to arrive because we don't know how long it will take. This means that we have to do it synchronously - instead of letting app_server send the 2nd _UPDATE_ request, we tell him to give it now as an attachment to the reply sent for our query message. In this way, we can be 95% sure that UpdateIfNeeded(), really updated all that was to be updated. The remaining 5% come from the fact that another regions of our window may become invalid while the 2nd _UPDATE_ request would be over and the story could continue. So, I think it's better we leave it the way it is now. >>>But as I think about it: it's a bad idea that there is always only >>>one >>>_UPDATE_ message in the queue, as it slows down the whole thing >>>quite a >>>lot; the latency between to (necessary) _UPDATE_ messages is >>>increased >>>a lot this way and for no reason. >> >> It is a bit lengthly to explain why we do that. But believe me, >>what we >>do it's OK. (It's optimal too. :-) ) > > See above. See above. :-) > I think the optimal solution would be to do quite the > opposite: hammering the app with contiguous _UPDATE_ messages (of > course, the update rate could be limited), and the app must then decide > on how to combine them for one actual drawing update. No, not good. That's how it was before Stephan start complaining about how update code was not working good. Having things as you want will result in (very) complicated code, which I really think is not more optimal. > That would be quite similar to what you propose above, with the > difference that the data is there when it's needed, and is not queried > for at that time (which increases latency). Don't worry! (It's no sugar! :-)) Pepsi) When we'll have a beta you'll see there are no latency problems. (I really don't want to start talking about this issue again, I spent a lot of time writing about this a couple months ago.) bye, Adi.