On Tue, 30 Aug 2011 09:41:56 -0600 DRC <dcomman...@users.sourceforge.net> 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. > 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. :) > 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. 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. 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. > 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. > 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. > OpenMP requires additional library dependencies, etc. that are > undesirable for our project. Those should be possible to link statically like we do with other libraries. And the whole point of OpenMP is that it is an optional dependency. A compiler without it will simply produce single threaded code. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
