On 8/30/11 6:06 AM, Pierre Ossman wrote: >> It already does this. Only the tiles that were previously sent with >> lossy compression are re-sent during an ALR. > > Yes, but I meant that we could also split those parts into smaller > pieces. E.g. say that 50% of the screen is "lossy". But that's a lot of > data, so we only send 10% ALR in each update. Eventually all of the > screen will have been updated, but if any "real" updates were needed, > we wouldn't have a big queue of ALR to wait for first.
I don't follow. ALR is only ever relevant for one frame at a time. It won't ever be sent unless the connection is completely idle for a specified period of time, so it can't be sent on multiple frames because there aren't multiple frames for it to piggyback on-- the connection is idle. Also, that means that no one is "waiting" on ALR. Arguing hypotheticals on the ALR feature serves no purpose. It is already out in the field right now, people are using it actively, and it can easily be tested by you and others. Why not just test it and see how it currently behaves, then give more targeted feedback about its behavior? > Hmm.. I remember looking at this. Unfortunately, I seem to recall that > it was more or less useless. It didn't solve the existing > synchronisation issues of the protocol, and it introduced new ones. I > don't think that variant can server any purpose other than as a proof > of concept. What do you mean useless? There are some things that need tweaking, but we've implemented it, and it works. The CU extension is the "official" way that a VNC viewer can notify a VNC server that it wants to begin server-side streaming. Without it, if we just start streaming from the server with any VNC client, we're in violation of the spec. >> I'm familiar with OpenMP, but I don't see it as really being a good >> solution for this. When you say "most compilers", of course the ones >> I'm currently using to build TigerVNC aren't included in that, and we >> really need more control over the threads. Since the implementation in >> TurboVNC is quite stable at this point, I can just borrow a lot of the >> logic from there. > > Wikipedia indicates that both Microsofts compilers as well as gcc > supports it. That should cover the majority of cases? > > I'm concerned that even though you have code in TurboVNC, there will > still be a lot of changes (and bugs) as TurboVNC is based on a very > different RealVNC code base. So you really think that *any* feature can be implemented without some bugs creeping in? Since I'm the one likely to be developing the code, why don't you just let me develop it in the way I'm most comfortable? I am not proposing to directly port the code from TurboVNC-- such would be impossible, since it's written in C and TigerVNC is written in C++. I will create a thread wrapper class, of course, so that the resulting code will be easy to maintain. OpenMP requires additional library dependencies, etc. that are undesirable for our project. >> We can't ever be 100% >> server-driven, because the client still has to send FBUR's whenever a >> portion of its window is obscured, etc. However, in order to get decent >> WAN performance, we are going to have to become mostly server-driven, at >> least under certain circumstances. > > I think server driven should be the norm. The VNC design was just a > quick and easy way to solve the flow control issues and is not a good > way to move forward. (IMO) I agree, generally, and I think we could accomplish it in our implementation by implementing a separate encode/send thread for each client and a true back buffer on the client (so it doesn't have to ask for framebuffer updates whenever a window obscures the client window, etc. However, being server-driven while still maintaining backward compatibility with other VNC clients is going to be the trick. That's why the CU extension exists-- as a way of bridging that gap. ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
