[Tigervnc-devel] [ tigervnc-Feature Request Tracker-2674740 ] Create JPEG encoding
Feature Request Tracker item #2674740, was opened at 2009-03-09 11:39 Message generated for change (Comment added) made by ossman_ You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126849aid=2674740group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: trunk Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Adam Tkac (atkac) Assigned to: Pierre Ossman (ossman_) Summary: Create JPEG encoding Initial Comment: JPEG encoding should be splitted to separate encoding. It will make it easy-to-use for other VNC implementations. -- Comment By: Pierre Ossman (ossman_) Date: 2011-09-01 11:13 Message: This is not a good forum for these discussion, and I don't plan to implement this right now anyway, so we can continue this later. Suffice to say, there is nothing in the protocol that restricts things to a single encoding. Real's server implementation does, but that's an implementation detail that we can change. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-30 17:44 Message: Still don't buy it. How can you use multiple encodings at the same time? The RFB protocol doesn't allow that. Thus, you could either have to use JPEG encoding, or something else, and using JPEG by itself has been proven to be less effective than using the layer cake. Tight encoding works. Let's not fix it unless there is a compelling reason to, and so far, I haven't heard one. -- Comment By: Pierre Ossman (ossman_) Date: 2011-08-30 17:28 Message: Yes, using _only_ JPEG is probably not a good idea. But this bug is one piece of the puzzle of moving away from the needless layer cake that the Tight encoding introduces. Moving forward, JPEG is fairly clearly one of the encodings we want to use. Therefore it would be beneficial for the entire VNC community if this encoding could be used without the rest of the cruft that Tight introduces. -- Comment By: Adam Tkac (atkac) Date: 2011-08-30 12:13 Message: Thanks for detailed inspection. The report clearly shows there is no user-visible benefit from the separate JPEG encoding. Closing. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-09 23:03 Message: This report: http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf explains why a pure JPEG encoding method is not a good idea. TurboVNC went down that road at first and discovered later that a mix of indexed color and JPEG subrectangles provided the best balance of compression ratio and performance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126849aid=2674740group_id=254363 -- 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
Re: [Tigervnc-devel] [PATCH] Multithreaded ComparingUpdateTracker
On Wed, 31 Aug 2011 09:54:26 -0600 DRC dcomman...@users.sourceforge.net wrote: Have you done any research to validate the usefulness of the ComparingUpdateTracker? Personally, I found that, in Xvnc, it wasn't catching very many duplicate updates, and the dupes it was catching would not have significantly slowed down performance (they tended to be areas of solid color, which the Tight encoder already optimizes out.) The CUT might be beneficial in cases where an ill-behaved app draws the same frame over and over again, but that is a corner case, not the norm. We've seen issues in the past where the update tracker has solved things. It has always been crappy applications that keep redrawing the same thing over and over again. If memory serves me, Java was a bad offender here. Peter, do you remember any details? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: 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
Re: [Tigervnc-devel] Advanced TigerVNC features for 3D and streaming video workloads
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 OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: 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
Re: [Tigervnc-devel] [PATCH] Multithreaded ComparingUpdateTracker
On Thu, 1 Sep 2011, Pierre Ossman wrote: Have you done any research to validate the usefulness of the ComparingUpdateTracker? Personally, I found that, in Xvnc, it wasn't catching very many duplicate updates, and the dupes it was catching would not have significantly slowed down performance (they tended to be areas of solid color, which the Tight encoder already optimizes out.) The CUT might be beneficial in cases where an ill-behaved app draws the same frame over and over again, but that is a corner case, not the norm. We've seen issues in the past where the update tracker has solved things. It has always been crappy applications that keep redrawing the same thing over and over again. If memory serves me, Java was a bad offender here. Peter, do you remember any details? We have seen that VNC is a great improvement over X11 with Java applications, but I'm not sure if we have verified if the ComparingUpdateTracker is causing the improvement or not. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- 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
Re: [Tigervnc-devel] Advanced TigerVNC features for 3D and streaming video workloads
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
