Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4635] trunk/java/src/com/tigervnc/vncviewer
Is there still a way of overriding this and specifying 7-9 at a lower
level (from the command line or in the parameters, etc.?)
I'm a little uncomfortable completely removing those levels
functionally, because maybe there's some rare corner case in which they
still benefit. I personally haven't seen such a case, but if it does
pop up, I want to be able to tell the user how to manually specify the
higher compression levels.
On 8/17/11 9:37 AM, bph...@users.sourceforge.net wrote:
> Revision: 4635
> http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4635&view=rev
> Author: bphinz
> Date: 2011-08-17 14:37:41 + (Wed, 17 Aug 2011)
>
> Log Message:
> ---
> Implement recommendations from low-level performance study into java client.
> Mirrors the changes made to the Fltk viewer in r4632.
>
> Modified Paths:
> --
> trunk/java/src/com/tigervnc/vncviewer/OptionsDialog.java
> trunk/java/src/com/tigervnc/vncviewer/VncViewer.java
>
> Modified: trunk/java/src/com/tigervnc/vncviewer/OptionsDialog.java
> ===
> --- trunk/java/src/com/tigervnc/vncviewer/OptionsDialog.java 2011-08-17
> 11:24:58 UTC (rev 4634)
> +++ trunk/java/src/com/tigervnc/vncviewer/OptionsDialog.java 2011-08-17
> 14:37:41 UTC (rev 4635)
> @@ -87,9 +87,9 @@
> JPanel tightPanel = new JPanel(new GridBagLayout());
> customCompressLevel = new JCheckBox("Custom Compression Level");
> customCompressLevel.addItemListener(this);
> -Object[] compressionLevels = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> +Object[] compressionLevels = { 1, 2, 3, 4, 5, 6 };
> compressLevel = new JComboBox(compressionLevels);
> -JLabel compressionLabel = new JLabel("Level (1=fast, 9=best)");
> +JLabel compressionLabel = new JLabel("Level (1=fast, 6=best [4-6 are
> rarely useful])");
> noJpeg = new JCheckBox("Allow JPEG Compression");
> noJpeg.addItemListener(this);
> Object[] qualityLevels = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
>
> Modified: trunk/java/src/com/tigervnc/vncviewer/VncViewer.java
> ===
> --- trunk/java/src/com/tigervnc/vncviewer/VncViewer.java 2011-08-17
> 11:24:58 UTC (rev 4634)
> +++ trunk/java/src/com/tigervnc/vncviewer/VncViewer.java 2011-08-17
> 14:37:41 UTC (rev 4635)
> @@ -253,8 +253,8 @@
>IntParameter compressLevel
>= new IntParameter("CompressLevel",
> "Use specified compression level "+
> - "0 = Low, 9 = High",
> - 6);
> + "0 = Low, 6 = High",
> + 1);
>BoolParameter noJpeg
>= new BoolParameter("NoJPEG",
>"Disable lossy JPEG compression in Tight
> encoding.", false);
>
>
> This was sent by the SourceForge.net collaborative development platform, the
> world's largest Open Source development site.
>
> --
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> ___
> Tigervnc-commits mailing list
> tigervnc-comm...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tigervnc-commits
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] xserver / cmake issues
On 8/17/11 4:01 PM, Martin Koegler wrote: > First of all, Makefile.am is missing some include path, so that a out of > source tree build fails (xserver 1.7): > --- tigervnc-1.0.1.svn0.orig/unix/xserver/hw/vnc/Makefile.am > +++ tigervnc-1.0.1.svn0/unix/xserver/hw/vnc/Makefile.am > @@ -17,7 +17,8 @@ libvnccommon_la_SOURCES = $(HDRS) vncExt > > libvnccommon_la_CPPFLAGS = -DVENDOR_RELEASE="$(VENDOR_RELEASE)" \ > -DVENDOR_STRING="\"$(VENDOR_STRING)\"" -I$(TIGERVNC_SRCDIR)/common > -UHAVE_CONFIG_H \ > - -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) > -I$(includedir)/pixman-1 -I$(includedir) > + -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) > -I$(includedir)/pixman-1 -I$(includedir) \ > + -I$(top_srcdir)/include > > bin_PROGRAMS = Xvnc > > @@ -49,6 +50,7 @@ libvnc_la_CPPFLAGS = $(XVNC_CPPFLAGS) -I > -I$(top_srcdir)/hw/xfree86/common \ > -I$(top_srcdir)/hw/xfree86/os-support \ > -I$(top_srcdir)/hw/xfree86/os-support/bus \ > + -I$(top_srcdir)/include \ > -I$(includedir)/pixman-1 -I$(includedir) > > libvnc_la_LDFLAGS = -module -avoid-version > > My second problem is, that it seems no longer possible to build the vnc > module. Linking the > vnc module for the Xserver leads to an linker error, because cmake only > generates non-PIC object files (eg libnetwork). > autotools+libtool did this automatically. How are you trying to build the module? I honestly only ever use build-xorg, which automatically adds the -fPIC flag, but I understand that a different procedure is required on more modern systems. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] xserver / cmake issues
First of all, Makefile.am is missing some include path, so that a out of source tree build fails (xserver 1.7): --- tigervnc-1.0.1.svn0.orig/unix/xserver/hw/vnc/Makefile.am +++ tigervnc-1.0.1.svn0/unix/xserver/hw/vnc/Makefile.am @@ -17,7 +17,8 @@ libvnccommon_la_SOURCES = $(HDRS) vncExt libvnccommon_la_CPPFLAGS = -DVENDOR_RELEASE="$(VENDOR_RELEASE)" \ -DVENDOR_STRING="\"$(VENDOR_STRING)\"" -I$(TIGERVNC_SRCDIR)/common -UHAVE_CONFIG_H \ - -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) -I$(includedir)/pixman-1 -I$(includedir) + -I$(TIGERVNC_SRCDIR)/unix/vncconfig $(XVNC_CPPFLAGS) -I$(includedir)/pixman-1 -I$(includedir) \ + -I$(top_srcdir)/include bin_PROGRAMS = Xvnc @@ -49,6 +50,7 @@ libvnc_la_CPPFLAGS = $(XVNC_CPPFLAGS) -I -I$(top_srcdir)/hw/xfree86/common \ -I$(top_srcdir)/hw/xfree86/os-support \ -I$(top_srcdir)/hw/xfree86/os-support/bus \ + -I$(top_srcdir)/include \ -I$(includedir)/pixman-1 -I$(includedir) libvnc_la_LDFLAGS = -module -avoid-version My second problem is, that it seems no longer possible to build the vnc module. Linking the vnc module for the Xserver leads to an linker error, because cmake only generates non-PIC object files (eg libnetwork). autotools+libtool did this automatically. Regards, Martin Koegler -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Xvnc performance optimizations completed
OK, I'm an idiot. The TigerVNC Server with the ComparingUpdateTracker disabled was not generating twice the data when the TurboVNC Viewer connected. I had simply forgotten the way that TurboVNC maps its 1-100 quality scale to TigerVNC's 1-9 quality scale, so in fact I was comparing JPEG quality 92 with JPEG quality 100, which is a difference in compression ratio of about 2x. Blerg. We now return you to your regularly-scheduled program. So, in short, with the right settings, I can now produce exactly the same performance with the TurboVNC Viewer connecting to the TigerVNC Server and the TurboVNC Server. I think our Unix server is pretty much golden performance-wise, unless someone discovers any other issues. To the latter end, I've generated a new trunk build with the Xvnc perf. enhancements and new default viewer settings: http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases This also has the "custom compression level" bug fix that went into 1.1.0. On 8/17/11 1:40 AM, DRC wrote: > Under sponsorship by Cendio, I have completed an extensive (as in 100+ > hours) set of performance optimizations to the TigerVNC Server in trunk, > which should bring its performance completely in line with TurboVNC, > provided that the ComparingUpdateTracker is disabled. I am > investigating the afore-mentioned issue with that whereby it is sending > twice as much data as it should when legacy clients are connected, and > pending a fix for that, I will likely recommend disabling the tracker as > the default. > > The process of optimizing the server involved the following steps: > > (1) High-level benchmarking and differential performance analysis to > determine the baseline relative to TurboVNC. TigerVNC trunk was > determined to be about 30-40% slower at the high level, and at the low > level, the server was using about 65% more CPU time to encode the same > data as TurboVNC. > > (2) Low-level analysis of the encoder using the processes described in > the following reports: > > http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf > http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf > > In a nutshell, the encoder was studied in isolation using a set of > low-level RFB performance tools and protocol captures. The link to the > code for these tools, including the isolated TigerVNC 1.1 and 1.2 > encoders, is provided in the reports. The isolated encoder has already > proven its usefulness in other areas (I used it to isolate the Zlib bug > and verify the low-level stability of the fix.) > > (3) After the low-level analysis was complete, I started integrating the > modified encoder back into TigerVNC, only to discover that one of the > main performance features that was added to it-- the pre-computation of > solid rectangles-- required another feature: last rectangle encoding. > Thus, I had to implement last rectangle encoding in the TigerVNC > transport layers. > > (4) At this point, we had an encoder that produced the same output as > TurboVNC and performed similarly to TurboVNC at the low levels, but the > high-level performance was still lacking. This was due to two factors: > (a) the afore-mentioned ComparingUpdateTracker, and (b) the image > getter. The process of getting the images from the framebuffer to the > encoder was very inefficient. Thus, I went back and overhauled the > encoder again, this time porting in the code from TurboVNC that allows > the encoder to compute solid rectangles, count colors, and compress JPEG > directly from the framebuffer without transforming the pixels first. > This involved some re-architecture to several of the classes in librfb > to allow access to the virtual FB from within the encoders. There is > probably a cleaner way to do what I did, but IMHO, it's at least cleaner > now than it was. > > > As of now, with the ComparingUpdateTracker disabled and using our FLTK > viewer, the performance is at about 85-90% of TurboVNC at the high > levels, and the remaining gap is entirely due to the viewer. The server > CPU usage is now almost exactly the same as TurboVNC. Whereas the FLTK > viewer is a bit more efficient than the old X viewer, it still needs > some optimization work, which I'll begin looking at next month. > > > In the meantime, please be on the lookout for potential performance > pitfalls in the new encoder, particularly on low-bandwidth networks. If > you discover situations in which the new Xvnc appears to produce worse > performance than the old Xvnc, please try your best to quantify the > difference and verify whether jacking up the compression level a notch > or two restores the performance you expect (it should, unless I miss my > guess.) > > > The viewer GUI has also been modified to reflect the findings from the > low-level performance study (specifically, that compression levels > higher than 3 rarely have any benefit and compression levels higher than > 6 never do. Also, compression level 1 is now
