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=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: 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=detail&atid=1126849&aid=2674740&group_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
