Feature Request Tracker item #2674740, was opened at 2009-03-09 05:39 Message generated for change (Comment added) made by dcommander You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=2674740&group_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: D. R. Commander (dcommander) Date: 2011-09-06 21:56 Message: I'm not going to argue the point further, but personally, I prefer to discuss things like this in tracker items, because the conversation is easier for people to locate later on. I will also say that, in order for me to get behind this proposal, it would have to have a clearly demonstrable end user benefit. There is no need to change something that works well unless it allows us to do something that we can't already do. ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2011-09-01 04: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 10: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 10: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 05: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 16: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=detail&atid=1126849&aid=2674740&group_id=254363 ------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
