On 9/1/11 3:34 AM, Pierre Ossman wrote: >> 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. >> > > It doesn't need to piggyback. It could generate its own > framebuffer updates.
Yes, but I still don't understand why you would want to send multiple updates for a single 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? > > This wasn't meant as criticism. I think the ALR feature is an awesome > improvement. I was just trying to toss up ideas for improving things > further. :) I didn't take it as criticism. I'm just having trouble understanding exactly what you're proposing vis-a-vis improving it. > There is nothing more "official" about this extension than anything we > can come up with. It's not widely implemented, or even properly > documented. > > It works as a proof of concept, but I don't believe the remaining > issues can be solved without changing the protocol. So we need a new > extension anyway. What remaining issues? > We don't need to discuss this further right now. I intend to focus on > this area for the next months. We can resume this when I have something > more substantial to show. We do need to discuss this further, because Cendio is paying me to look at this problem as well. If you're going to go off and re-design the whole VNC protocol, the rest of the project contributors need to be in the loop. >> 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? > > For the same reason you object to our changes now and then. It causes > maintenance problems for all of us. Threads are particularly devious at > this as the concurrency issues often creep into the entire program, and > not just the section that needed the threads. My practical experience with the multi-threaded encoder in TurboVNC does not bear this out. In fact, what it bears out is the fact that you need to keep the parallel compression threads running for the duration of the connection in order to avoid the overhead of creating/destroying them for each rectangle that is encoded. Based on my previous experience with OpenMP, I don't think it can do that. I'm pretty sure it spawns threads as needed. >> 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. > > I have yet to see thread code that doesn't incur a maintenance > overhead. So colour me sceptical. I have yet to see OpenMP code that doesn't incur a larger maintenance overhead. The more you abstract things, the more difficult it often becomes to diagnose performance issues. ------------------------------------------------------------------------------ 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
