[Tigervnc-devel] H.264 Encoding in VNC
NOTE: if you are receiving this message but you aren't on the [turbo|tiger]-devel mailing lists, it's because I BCC'ed you. Don't panic. :) The following article provides details of low-level tests I performed this week to assess the feasibility of using x264 (probably the most popular H.264 open source codec) as a replacement or a supplement for the TurboVNC encoder: http://www.turbovnc.org/About/H264 In short, at the moment, I find H.264 to be somewhat less than compelling. As predicted, the full-frame nature of the codec makes it a poor fit for VNC, it can only be shown to provide better compression on a very limited set of workloads, and despite SIMD acceleration, x264 is still really slow compared to the TurboVNC encoder (H.264 seems to be somewhat less symmetric, compared to JPEG, in terms of its CPU usage on the encoder and decoder side.) The codec is currently so slow that it would be CPU-bound, even on very slow broadband or satellite connections, so what's the point? Feedback is, as always, welcome. DRC -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Github migration?
On 6/23/14 5:39 AM, Pierre Ossman wrote: I'd like to keep the ball rolling here, so unless anyone objects I intend to start officially setting things up this week. One thing I wanted to ask-- you had mentioned that you were migrating only the recent commits. Why not migrate the whole SVN repository? I would think that this would be relatively straightforward. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] uVNC Repeater Mode II - Support - Enhancement Patch Request - Java Viewer
A more comprehensive version that also supports UltraVNC Repeater Mode I has been checked into the TurboVNC subversion trunk. I implemented it by extending the existing Via parameter (comments welcome.) Feel free to borrow it if you find it useful. NOTE: Mode I is using the repeater as a gateway, whereby it sits between the server network and the outside world. In this case, the viewer makes a forward connection into the repeater, and in response to the fake 000:000 version message, the viewer sends back the VNC server name that the repeater should connect to (e.g. localhost:1.) The repeater then issues a forward connection to that server. Mode II is more of a GoToMeeting paradigm, whereby the server and viewer both connect to the repeater (a forward connection from the viewer, and a reverse connection from the server.) In this case, the VNC server name specified in the viewer takes on the form ID:, where is the ID of the server that has connected (or will connect) to the repeater. The UltraVNC Server currently supports specifying a connection ID with reverse connections, but in TigerVNC and TurboVNC, vncconnect would have to be extended to support this (I don't imagine it would be very difficult to do that.) On 4/27/14 12:22 AM, Brian Hinz wrote: Thanks for the patch. I will review it and get back to you. -brian -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Simplifying compression levels in the TigerVNC GUI
://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf), we
already know that CL 6 is the maximum useful mode in TigerVNC. Well, in
fact, CL 5 and CL 6 are virtually identical in TigerVNC. The only major
difference is that CL 5 uses Zlib level 4 for raw subrects and CL 6 uses
Zlib level 5 for raw subrects, so that difference is irrelevant when
JPEG is enabled.
TigerVNC CL 9 vs. TigerVNC CL 5:
-- Compression Ratio for 2D datasets: +0.10% to +2.6% (avg +0.80% for
Q80, 1.1% for Q37)
-- Compression Ratio for 3D datasets: +0% to +4.8%(avg +0.69% for
Q80, 1.1% for Q37)
-- Speedup for 2D datasets (libjpeg): -74% to -29%(avg -61% for
Q80, -61% for Q37)
-- Speedup for 3D datasets (libjpeg): -85% to +0.59% (avg -68% for
Q80, -70% for Q37)
In TigerVNC, CL 5 is the maximum useful compression level when JPEG is
enabled. As with TightVNC, increasing the compression level beyond this
has only a negligible impact on compression ratio and a very significant
negative impact on performance. As with TightVNC, this produces a
situation in which the server CPU is the primary bottleneck on any
network faster than a few megabits/sec. With JPEG disabled, the maximum
useful level turns out to be CL 7, but only because CL 7 sets the raw
Zlib level to 6 instead of 5. From the research with the TurboVNC
encoder, it became apparent that using Zlib levels 7 was never
beneficial. Thus, it turns out that we can set the Zlib levels in
TigerVNC CL 6 to 7,7,6 (the same as TightVNC CL 6) and get the
compression ratio to within +/- 5% of TigerVNC CL 9 in all cases,
including with JPEG disabled.
So let's see where TigerVNC stands with respect to TightVNC:
TigerVNC CL 5 vs. TightVNC CL 6:
-- Compression Ratio for 2D datasets:-28% to +11% (avg -9.4%
for Q80, -3.7% for Q37)
-- Compression Ratio for 3D datasets:-3.6% to +133% (avg +56%
for Q80, +10% for Q37)
-- Speedup for 2D datasets (libjpeg):-38% to +50% (avg +9.9%
for Q80, +8.6% for Q37)
-- Speedup for 3D datasets (libjpeg):+6.9% to +138% (avg +67%
for Q80, +33% for Q37)
-- Speedup for 2D datasets (libjpeg-turbo): -37% to +200% (avg +35%
for Q80, +28% for Q37)
-- Speedup for 3D datasets (libjpeg-turbo): +43% to +594% (avg +155%
for Q80, +94% for Q37)
TigerVNC is in a better position than TurboVNC was, but we're still
dealing with some large negative outliers relative to TightVNC.
However, changing the parameters of TigerVNC CL 9 such that a palette
threshold of 256 and Zlib levels 7, 7, and 6 are used produces very
similar results to the new TurboVNC CL 9.
Thus, I make the following proposals:
-- Cap the Zlib levels used by the Tight encoder in TigerVNC to 7 for
indexed and mono subrects and to 6 for raw subrects
-- Change the Zlib levels of CL 5 and CL 6 to match those used in TightVNC
-- Set the palette threshold of CL 9 to 256.
--- TightEncoder.cxx(revision 5946)
+++ TightEncoder.cxx(working copy)
@@ -67,11 +67,11 @@
{ 65536, 2048, 8, 3, 3, 2, 24, 96, 41, SUBSAMP_420 }, // 2
{ 65536, 2048, 12, 5, 5, 2, 32, 96, 42, SUBSAMP_422 }, // 3
{ 65536, 2048, 12, 6, 7, 3, 32, 96, 62, SUBSAMP_422 }, // 4
- { 65536, 2048, 12, 7, 8, 4, 32, 96, 77, SUBSAMP_422 }, // 5
- { 65536, 2048, 16, 7, 8, 5, 32, 96, 79, SUBSAMP_NONE }, // 6
- { 65536, 2048, 16, 8, 9, 6, 64, 96, 86, SUBSAMP_NONE }, // 7
- { 65536, 2048, 24, 9, 9, 7, 64, 96, 92, SUBSAMP_NONE }, // 8
- { 65536, 2048, 32, 9, 9, 9, 96, 96,100, SUBSAMP_NONE } // 9
+ { 65536, 2048, 12, 7, 7, 5, 32, 96, 77, SUBSAMP_422 }, // 5
+ { 65536, 2048, 16, 7, 7, 6, 32, 96, 79, SUBSAMP_NONE }, // 6
+ { 65536, 2048, 16, 7, 7, 6, 64, 96, 86, SUBSAMP_NONE }, // 7
+ { 65536, 2048, 24, 7, 7, 6, 64, 96, 92, SUBSAMP_NONE }, // 8
+ { 65536, 2048, 32, 7, 7, 6, 96, 256,100, SUBSAMP_NONE } // 9
};
const int TightEncoder::defaultCompressLevel = 1;
What this does, conceptually:
-- CL 6 in TigerVNC is now, in almost all cases, the maximum useful
mode. This matches what the GUI already says (1=fast, 6=best, 4-6 are
rarely useful).
-- If someone decides that they want to jack it up to CL 9, this will
never have a negative effect on compression ratio relative to CL 6, but
whether it has a significant benefit will depend on the workload. On
average, 2D datasets will compress 10% better with a 10% loss in
performance, and on average, 3D datasets will compress 3% better with a
10% loss in performance. That's a lot nicer of a trade-off than the
current CL 9 provides (basically no compression benefit with 4-5x more
CPU usage.)
-- CL 7 and 8 will basically perform the same as CL 6.
On 1/23/14 4:01 AM, Pierre Ossman wrote:
On Wed, 22 Jan 2014 17:30:25 -0600,
DRC wrote:
My proposal is for TigerVNC to adopt four compression modes: CL 0, CL
1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to
5, and the GUI could be restructured so that it sets the compression
level to low, high
Re: [Tigervnc-devel] Simplifying compression levels in the TigerVNC GUI
On 1/25/14 3:04 PM, DRC wrote: -- If someone decides that they want to jack it up to CL 9, this will never have a negative effect on compression ratio relative to CL 6, but whether it has a significant benefit will depend on the workload. On average, 2D datasets will compress 10% better with a 10% loss in performance, and on average, 3D datasets will compress 3% better with a 10% loss in performance. That's a lot nicer of a trade-off than the current CL 9 provides (basically no compression benefit with 4-5x more CPU usage.) I should clarify that that 10% gain with the new proposed CL 9 is generally only realized if the JPEG quality is medium or higher. With low-quality JPEG, the existing TigerVNC CL 5 already performs almost on par with TightVNC in most cases (except that pesky photos dataset again.) But anyhow, the new CL 9 offers a real option, whereas the existing CL 9 is not a real option. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Simplifying compression levels in the TigerVNC GUI
Further analysis reveals that TigerVNC's Compression Level 5 and 6
(which are basically identical when JPEG is enabled) can already produce
roughly the same compression ratio (within +/- 5%) as the maximum useful
mode in TightVNC 1.3.x, so actually, I think the only thing that might
need addressing here is the fact that the higher Zlib levels are not
needed for Compression Levels 7-9. I can find no dataset for which
moving from CL 6 to CL 9 in TigerVNC produces more than a 5% increase in
compression ratio, and generally this move increases CPU time by a
factor of 4-5. Thus, I would suggest the following modification, which
extends the Zlib levels from CL 6 through CL 7-9 as well:
--- a/common/rfb/TightEncoder.cxx
+++ b/common/rfb/TightEncoder.cxx
@@ -70,9 +70,9 @@ const TIGHT_CONF TightEncoder::conf[10] = {
{ 65536, 2048, 12, 6, 7, 3, 32, 96, 62, SUBSAMP_422 }, // 4
{ 65536, 2048, 12, 7, 8, 4, 32, 96, 77, SUBSAMP_422 }, // 5
{ 65536, 2048, 16, 7, 8, 5, 32, 96, 79, SUBSAMP_NONE }, // 6
- { 65536, 2048, 16, 8, 9, 6, 64, 96, 86, SUBSAMP_NONE }, // 7
- { 65536, 2048, 24, 9, 9, 7, 64, 96, 92, SUBSAMP_NONE }, // 8
- { 65536, 2048, 32, 9, 9, 9, 96, 96,100, SUBSAMP_NONE } // 9
+ { 65536, 2048, 16, 7, 8, 5, 64, 96, 86, SUBSAMP_NONE }, // 7
+ { 65536, 2048, 24, 7, 8, 5, 64, 96, 92, SUBSAMP_NONE }, // 8
+ { 65536, 2048, 32, 7, 8, 5, 96, 96,100, SUBSAMP_NONE } // 9
};
On 1/23/14 4:01 AM, Pierre Ossman wrote:
On Wed, 22 Jan 2014 17:30:25 -0600,
DRC wrote:
My proposal is for TigerVNC to adopt four compression modes: CL 0, CL
1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to
5, and the GUI could be restructured so that it sets the compression
level to low, high, and very high, with a warning that very high is
only better than high in some rare cases.
Just a suggestion. I can provide a server-side patch for this if requested.
Interesting stuff. I'd definitely like to know more about the
discussion and the testing that was done.
I'm shuffling around all of that code at the moment though, so please
hold off on that patch for a while. :)
Rgds
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Simplifying compression levels in the TigerVNC GUI
Last year, I got involved in a project to port the TurboVNC encoder into libvncserver, and in the process of doing this, I had to prove that the Turbo encoder was capable of producing at least roughly equivalent compression to the tightest modes in the TightVNC encoder. There are lengthy threads on the libvncserver mailing list that I am happy to provide links to for the morbidly curious, but I'll summarize the findings here. The research revealed that, for starters, any compression level greater than 5 in TightVNC was wholly useless. It increased CPU time by as much as an order of magnitude without any significant compression ratio increase for the test datasets (which include Constantin's original 2D datasets that were used in the design of the Tight encoder, as well as 3D datasets I provided.) In some cases, going from CL 5 to CL 9 actually decreased the compression ratio. This is known to be true of TigerVNC as well (referring to http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf). It was also discovered that CL 2 in TurboVNC (or TigerVNC) could not quite achieve the same compression as TightVNC in all cases, so I developed a TightVNC replacement mode in TurboVNC, a mode that strongly favors the use of Zlib-encoded subrectangles instead of JPEG-encoded subrectangles. Basically, it sets the palette threshold to 256, so all subrectangles that have 256 or fewer colors are encoded using indexed color (normally, the palette threshold is set to 24 or 96, so any subrectangles with more than that number of colors will be encoded using JPEG.) The TightVNC replacement mode provides equivalent or better compression to the tightest mode (CL 5) in TightVNC across all of the datasets, while using much less CPU time in general. The other thing about these compression levels is: once you get past CL 2, the incremental difference in each level starts becoming less and less. What I observe in TurboVNC is that: moving from CL 1 to CL 2: -- results in about a 15-20% aggregate bandwidth savings for 2D apps, while using on average about 20% more CPU time -- results in about a 10-15% aggregate bandwidth savings for 3D apps, while using on average about 15-20% more CPU time (there are a couple of outlying app workloads that see a 30-40% bandwidth savings, but these are not the common case.) moving from CL 2 to the TightVNC replacement mode: -- results in about a 15-30% aggregate bandwidth savings for 2D apps, while using on average about 20-40% more CPU time -- results in about a 7% aggregate bandwidth savings for 3D apps, while doubling the CPU time So, as you can see, anything more than CL 2 is not useful for 3D apps, and for 2D apps, pretty extreme measures are required in order to achieve the same incremental compression increase as that which is achieved by going from CL 1 to CL 2. My proposal is for TigerVNC to adopt four compression modes: CL 0, CL 1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to 5, and the GUI could be restructured so that it sets the compression level to low, high, and very high, with a warning that very high is only better than high in some rare cases. Just a suggestion. I can provide a server-side patch for this if requested. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Refactoring encoders
On 1/17/14 4:18 AM, Pierre Ossman wrote: Another FYI. As part of the cleanup, I am seriously considering removing colour map (i.e. palette) support. Reasons for doing so: - It's a lot of added complexity for something that is rarely, if at all, used today. - Our current viewer doesn't need it, and remote servers are required to support true color (i.e. it doesn't affect our ability to talk to other VNC servers). - We can still support colour map clients by giving them a generated palette based on e.g. 3-3-2 channels. IOW, our servers will still support all clients. The only downside I can see is that we lose built-in support for writing a TigerVNC server for a platform that uses palettes. I don't consider this a practical issue as those are rare. And should one come up, then you could put a conversion routine in the glue for that specific platform, rather than in the common code. Thoughts? Are you referring to colormap support at the RFB level or the X server level or both? -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Refactoring encoders
On 1/17/14 5:17 AM, Pierre Ossman wrote: As far as the code is concerned, both. The protocol still mandates support, hence the simple colour cube to support such clients (of which I expect few). Let me rephrase. Currently, when does that aspect of the protocol get invoked? My understanding (which may be incorrect) is that it's a relic of clients that don't have the ability to do pixel format conversion, so it would only come into play if the client was forced to use a PseudoColor visual and couldn't convert, thus requiring the server to do the conversion. It's been a while since I dealt with this stuff, so I'm probably getting something wrong. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Refactoring encoders
On 1/17/14 11:11 AM, Alan Coopersmith wrote: I think that's more a factor of using a video card driver that doesn't simulate PsuedoColor visuals on modern 32-bit graphics cards - I don't think we've removed PseudoColor support in Xorg completely, just not done much with it in years. Yeah, it's still possible to, for instance, enable PseudoColor visuals on nVidia Quadro hardware. They even still support using PseudoColor visuals with transparent overlays. But the set of apps that actually take advantage of those capabilities is a vanishing breed. PseudoColor visuals are no longer supported in OpenGL, as of version 3.1 (but nVidia, at least, still supports them in its drivers when using the compatibility profile.) Brian, I'm actually surprised that you are able to use TigerVNC with -depth 8 at all. When I've tried it on RHEL 5, Gnome basically eats its face. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Refactoring encoders
Regarding H.264, I have some interest in that as well, but I wasn't able to find a full specification for an H.264 RFB encoding, even though the encoding number is allocated. On Dec 18, 2013, at 3:27 AM, Pierre Ossman oss...@cendio.se wrote: Just wanted to give everyone a heads up on what I'm planning for the next few months. One area we here at Cendio would like to focus on is bandwidth usage and related user experience (latency, image quality, frame rate, etc.). In order to tackle this efficiently we believe we need a more flexible handling of encoders in the server. In short, my goal is to abstract the encoders to a more generic interface. This allows us to write a general core encoding selection routine that can do things like automatic encoder selection and lossless refresh. The tight encoder already has some of this logic and my plan is to move this up a layer so that we can benefit from other encoders (like H.264 and PNG). In the short term this will only be server changes. Long term the client might grow more extensions though to provide the server with the needed information to make a good decision (e.g. CPU power and which decoders are accelerated). Rgds -- Pierre Ossman Software Development Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Bug in Java RRE decoder
Does not display correct output at all. Fix attached. Apparently this was an oversight when the Java code was ported from C++. The fix does exactly the same thing as the C++ code does. *** java/com/tigervnc/rfb/RREDecoder.java 2013-09-16 20:37:32.0 -0500 --- /Volumes/Fezzik/Users/drc/src/vnc/java/com/turbovnc/rfb/RREDecoder.java 2013-09-16 17:28:20.0 -0500 *** *** 39,43 int w = is.readU16(); int h = is.readU16(); ! handler.fillRect(new Rect(x, y, w, h), pix); } } --- 39,44 int w = is.readU16(); int h = is.readU16(); ! handler.fillRect(new Rect(r.tl.x + x, r.tl.y + y, ! r.tl.x + x + w, r.tl.y + y + h), pix); } } -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Debian packing for pre-release builds
The goal of a cross-compatible build isn't necessarily to eliminate all dependencies but to eliminate dependencies that aren't forward ABI compatible with the platform on which you build or which might not be readily available. I would say that the goal should be to produce similar dependencies to TigerVNC 1.2. My build scripts for TigerVNC 1.2 are in the SVN repo. Why can't you reference those? On Jun 21, 2013, at 7:28 AM, Brian Hinz bph...@users.sourceforge.net wrote: On Fri, Jun 21, 2013 at 8:38 AM, D.L.C. Burggraaff burd...@gmail.com wrote: Yes, when I issued replace in an xterm I got the hint that replace was included in the mysql-server package. However, a mysql build dependency did not seem right to me. So now I installed mysql-server (with a slew of dependencies) and via the replace man page could analyze the pack_tiger.sh line 18.I replaced (sic) it by a 'sed -i -e s/Xvnc/Xtigervnc/g usr/bin/tigervncserver' command. Following the instructions as given previously the .deb was created ok. Double clicking on the deb produced a The package is of bad quality. The package doesn't provide a valid Installed-Size control field. See Debian Policy 5.6.20 popup, Pressing Ignore and install made the package install nevertheless. Running vncserver :60 and vncviewer localhost:60 was ok. As an aside, the /usr/share/vnc/classes/* files were not renamed and therefore may collide with an other VNC alternative. Kind regards, Dick On Thu, Jun 20, 2013 at 3:18 PM, Robert Goley rago...@rdasys.com wrote: The replace utility is part of the mysql server package. It is a handy string replacement tool. Just FYI, I don't mind incorporating this into the nightly build script, especially if you guys continue to provide guidance with the deb files. I've been trying to eliminate that libexpat dependency, but so far haven't managed to do so successfully. In theory, many of the dependencies on shared libraries could be eliminated from the vnc* binaries (vncviewer, vncpasswd, etc.) by linking against the static versions that I already have to build to link Xvnc against, but I'm having trouble getting the linker to pick them up. I suppose that the CMake files might need to be hacked a bit in order to make that happen cleanly... -brian -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Debian packing for pre-release builds
An additional note: dpkg-deb doesn't require a Debian-based machine in order to run, so it's pretty straightforward to generate DEBs on a Red Hat machine as part of an automated build procedure. I do this for VirtualGL and the other projects I maintain. On 6/17/13 1:37 PM, Robert Goley wrote: I worked up some basic Debian/Ubuntu packaging files for the binary cross compatible builds. Mine are only for the 64 bit release but it is only minor changes for using them with the 32 bit release. Had discussed Debian packaging with Brian previously so I wanted to share these with the group in case others are interested in using packages instead of the tarballs. To use them, extract the zip I provided. Then extract the binary tarball into the tigervnc subdirectory. CD into the tigervnc subdirectory and then run ../pack_tiger.sh. CD back one directory and then run dpkg-deb -b tigervnc tigervnc-1.2.90.deb to generate the package. Can easily be installed with dpkg -i or added to your custom repositories. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] MacOS-X nightly build updated
I've mentioned the performance issue before. Not sure what exactly is going on, but the TigerVNC native viewer on Mac is on the order of 10x slower than it should be. It has to be an FLTK issue. On Jun 10, 2013, at 8:08 AM, Robert Goley rago...@rdasys.com wrote: I haven't test 10.8 yet but it is working on 10.6. It is surprisingly slower at screen refreshing than the Java viewer. I will continue using the java viewer on this machine. I will report on 10.8 later. On Sun, Jun 9, 2013 at 2:37 PM, Brian Hinz bph...@users.sourceforge.net wrote: The OS-X pre-release build has been updated to fix backwards compatibility issues. I've verified that this new build works on OS-X 10.6 Snow Leopard Server and 10.7 Lion. It should work on 10.5 and 10.8 as well but I can't verify either of those (I'd appreciate it if anyone out there has a 10.5 and/or 10.8 machine and could take a few minutes to check and let me know). As usual, the nightly builds are available at: http://tigervnc.sourceforge.net/tiger.nightly/ Thanks, -brian -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] External dependencies in cross-compatible build
Pursuant to our discussion on tigervnc-users regarding whether the project RPMs could be used on SuSE, I noticed that the RHEL 5 RPMs and the cross-compatible build have external dependencies on GnuTLS and libstdc++. That prevents them from truly being cross-compatible. It should be possible to link statically with GnuTLS on the RHEL 5 builds, since RHEL 5 provides static library versions of GnuTLS. I'm confused as to why the libstdc++ dependency is there, since build-xorg is supposed to take care of that automatically. TigerVNC 1.2 Xvnc dependencies: linux-vdso.so.1 = (0x7fffbaba2000) libpam.so.0 = /lib64/libpam.so.0 (0x003b2fe0) libdl.so.2 = /lib64/libdl.so.2 (0x003b2be0) librt.so.1 = /lib64/librt.so.1 (0x003b3120) libm.so.6 = /lib64/libm.so.6 (0x003b2ba0) libc.so.6 = /lib64/libc.so.6 (0x003b2b60) libpthread.so.0 = /lib64/libpthread.so.0 (0x003b2c60) libaudit.so.0 = /lib64/libaudit.so.0 (0x003b2de0) /lib64/ld-linux-x86-64.so.2 (0x003b2b20) TigerVNC 1.3 Xvnc dependencies: linux-vdso.so.1 = (0x7fffc8569000) libgnutls.so.13 = /usr/lib64/libgnutls.so.13 (0x003b3f40) libz.so.1 = /lib64/libz.so.1 (0x003b2c20) libpam_misc.so.0 = /lib64/libpam_misc.so.0 (0x003b2da0) libpam.so.0 = /lib64/libpam.so.0 (0x003b2fe0) libcrypto.so.6 = /lib64/libcrypto.so.6 (0x003b3420) libdl.so.2 = /lib64/libdl.so.2 (0x003b2be0) librt.so.1 = /lib64/librt.so.1 (0x003b3120) libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x2b4b6762) libm.so.6 = /lib64/libm.so.6 (0x003b2ba0) libgcc_s.so.1 = /lib64/libgcc_s.so.1 (0x003b2de0) libc.so.6 = /lib64/libc.so.6 (0x003b2b60) /lib64/ld-linux-x86-64.so.2 (0x003b2b20) libgcrypt.so.11 = /usr/lib64/libgcrypt.so.11 (0x003b4100) libgpg-error.so.0 = /usr/lib64/libgpg-error.so.0 (0x003b4140) libaudit.so.0 = /lib64/libaudit.so.0 (0x2b4b67922000) libpthread.so.0 = /lib64/libpthread.so.0 (0x003b2c60) -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] External dependencies in cross-compatible build
On 5/17/13 2:01 PM, Brian Hinz wrote: I think I'm actually using a patch that you posted to the list sometime in Februaury(?). I wasn't able to build GnuTLS correctly on MinGW so I'm linking against the pre-compiled version listed in BUILDING.txt Ah. OK, that's what I'm doing as well. Just checking. Yeah, I was never able to build GnuTLS on Windows either and ended up using the same pre-compiled version, which meant that I could only supply a TLS-enabled build for Win32. The Win64 build never had GnuTLS support. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[5092] tags/1_2_90
Tags are supposed to be snapshots of a specific release. I think this
should have been copied into the 1.3 branch rather than the 1.3 beta1 tag.
On 5/7/13 5:50 PM, bph...@users.sourceforge.net wrote:
Revision: 5092
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5092view=rev
Author: bphinz
Date: 2013-05-07 22:50:48 + (Tue, 07 May 2013)
Log Message:
---
Copy r5088 5089 into 1_2_90 tag
Revision Links:
--
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5088view=rev
Modified Paths:
--
tags/1_2_90/cmake/Modules/CMakeMacroLibtoolFile.cmake
tags/1_2_90/release/tigervnc.iss.in
Modified: tags/1_2_90/cmake/Modules/CMakeMacroLibtoolFile.cmake
===
--- tags/1_2_90/cmake/Modules/CMakeMacroLibtoolFile.cmake 2013-05-07
13:03:01 UTC (rev 5091)
+++ tags/1_2_90/cmake/Modules/CMakeMacroLibtoolFile.cmake 2013-05-07
22:50:48 UTC (rev 5092)
@@ -101,8 +101,8 @@
# Add custom command to symlink the static library so that autotools finds
# the library in .libs. These are executed after the specified target
build.
add_custom_command(TARGET ${_target} POST_BUILD COMMAND
-cmake -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/.libs)
+${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/.libs)
add_custom_command(TARGET ${_target} POST_BUILD COMMAND
-cmake -E create_symlink ${_target_location}
${CMAKE_CURRENT_BINARY_DIR}/.libs/${_lname}${CMAKE_STATIC_LIBRARY_SUFFIX})
+${CMAKE_COMMAND} -E create_symlink ${_target_location}
${CMAKE_CURRENT_BINARY_DIR}/.libs/${_lname}${CMAKE_STATIC_LIBRARY_SUFFIX})
endmacro()
Modified: tags/1_2_90/release/tigervnc.iss.in
===
--- tags/1_2_90/release/tigervnc.iss.in 2013-05-07 13:03:01 UTC (rev
5091)
+++ tags/1_2_90/release/tigervnc.iss.in 2013-05-07 22:50:48 UTC (rev
5092)
@@ -21,7 +21,7 @@
[Files]
#ifdef BUILD_WINVNC
Source: @CMAKE_CURRENT_BINARY_DIR@\win\winvnc\winvnc4.exe; DestDir:
{app}; Flags: ignoreversion restartreplace;
-Source: @CMAKE_CURRENT_BINARY_DIR@\win\winvnc\wm_hooks.dll; DestDir:
{app}; Flags: ignoreversion restartreplace;
+Source: @CMAKE_CURRENT_BINARY_DIR@\win\wm_hooks\wm_hooks.dll; DestDir:
{app}; Flags: ignoreversion restartreplace;
Source: @CMAKE_CURRENT_BINARY_DIR@\win\vncconfig\vncconfig.exe; DestDir:
{app}; Flags: ignoreversion restartreplace;
#endif
Source: @CMAKE_CURRENT_BINARY_DIR@\vncviewer\vncviewer.exe; DestDir:
{app}; Flags: ignoreversion restartreplace;
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Tigervnc-commits mailing list
tigervnc-comm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-commits
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] SourceForge project upgrades start April 22 (fwd)
Unfortunately, SourceForge hasn't finished fixing all of the issues in the code viewer. They're choosing instead to force feed us this upgrade before it's fully cooked, and I am attempting to bring the issue to light as best I can, but there may not be much for it at the moment. Once the upgrade happens and more projects realize how broken the new system is, then perhaps we'll have the political capital to get SourceForge to do the right thing. On Apr 8, 2013, at 2:19 AM, Peter Åstrand astr...@cendio.se wrote: FYI. --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Forwarded message -- Date: Fri, 5 Apr 2013 18:35:23 + From: SourceForge.net Team nore...@sourceforge.net To: astr...@lysator.liu.se Subject: SourceForge project upgrades start April 22 Dear SourceForge project member, As you're no doubt already aware, we're in the process of upgrading projects to our new developer platform. The new platform is named Allura, and is in incubation at the Apache Software Foundation (http://incubator.apache.org/allura/). In recent weeks, we've been upgrading projects that have been inactive for a while. Now, it's time to start upgrading everyone else. As you can no doubt understand, we're anxious to complete this process so we can spend less time maintaining the old platform, and more time improving the new one. However, we also want to be sure that you have plenty of time to check out the new platform and have your concerns, if any, addressed. We're going to start upgrading active projects starting on Monday, April 22, starting with the longest-inactive and moving forward. Since each upgrade takes a different amount of time, depending on the size of the repositories, mailing list archives, and so on, we can't tell for sure when we'll get to your project. If you're ready to go ahead and upgrade your project now, you can do that at http://sf.net/p/upgrade/ If you have a specific concern about the upgrade, or need to delay the upgrade of your project, due to a release or other project activity, please get in touch NOW, at communityt...@sourceforge.net so that we can work something out. -- SourceForge Community Team communityt...@sourceforge.net http://sourceforge.net/ -- SourceForge.net has made this mailing to you as a registered user of the SourceForge.net site to convey important information regarding your SourceForge.net account or your use of SourceForge.net services. We make a small number of directed mailings to registered users each year regarding their account or data, to help preserve the security of their account or prevent loss of data or service access. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Updated FLTK modifications for 1.3.2
I'm attaching the FLTK patches that are still necessary to produce a
working FLTK build on all supported platforms, as well as re-introduce
the functionality lost when FLTK was pulled out of the TigerVNC tree.
These should be applied against the 1.3.2 FLTK code after the other
TigerVNC-specific patches are applied. 0002 and 0003 really need to be
submitted upstream, but I have no cycles to do so. 0001 probably needs
to be checked into the TigerVNC repository and applied by the script in
BUILDING.txt. 0001 adds the BUILD_STATIC CMake option that is necessary
to produce a cross-compatible binary on Linux and a transportable binary
on Windows. Otherwise, TigerVNC (via FLTK) will depend on the libgcc or
libstdc++ dynamic libraries, which are not system-supplied on Windows
(and which vary in compatibility between Linux distros.)
I also find that I have to add the following patch to TigerVNC whenever
building FLTK with a system-installed version (i.e. a dynamic library
version) of libpng:
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 5051)
+++ CMakeLists.txt (working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
if(FLTK_FOUND)
The workaround is to build FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0. On
Windows and Mac, I also pass -DOPTION_USE_SYSTEM_LIBJPEG=0
-DOPTION_USE_SYSTEM_ZLIB=0 to the FLTK build, and on Windows and Linux,
I use -DBUILD_STATIC=1 (see above.)
This information is provided as a courtesy. Suffice it to say that
these issues are easily reproducible by anyone attempting to build
32-bit and 64-bit binaries for OS X, Linux, and Windows. I am not
volunteering or accepting any responsibility for fixing the issues, nor
do I have time to debate them.
DRC
From 7a15d1c9a908afe429c1aba1c27516d18bdea299 Mon Sep 17 00:00:00 2001
From: DRC informat...@virtualgl.org
Date: Tue, 26 Feb 2013 03:37:12 -0600
Subject: [PATCH 1/4] Add BUILD_STATIC feature from TigerVNC to (optionally)
prevent FLTK from depending on libgcc and libstdc++
---
CMakeLists.txt | 43 +++
1 file changed, 43 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a1ee285..7d9d94b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -150,6 +150,49 @@ mark_as_advanced(LIB_CAIRO LIB_fontconfig LIB_freetype)
mark_as_advanced(LIB_GL LIB_MesaGL)
mark_as_advanced(LIB_jpeg LIB_png LIB_zlib)
+# This ensures that we don't depend on libstdc++ or libgcc
+if(CMAKE_COMPILER_IS_GNUCXX AND NOT APPLE AND NOT CYGWIN)
+ option(BUILD_STATIC
+Link statically against libgcc and libstdc++, if possible OFF)
+ if(BUILD_STATIC)
+# For some reason, simply passing ${CMAKE_CXX_FLAGS} to the compiler in
+# execute_process() doesn't work. Grrr...
+if(CMAKE_SIZEOF_VOID_P MATCHES 8)
+ execute_process(COMMAND ${CMAKE_CXX_COMPILER} -m64
+--print-file-name=libstdc++.a OUTPUT_VARIABLE LIBSTDCPLUSPLUS
+RESULT_VARIABLE RESULT)
+else()
+ execute_process(COMMAND ${CMAKE_CXX_COMPILER} -m32
+--print-file-name=libstdc++.a OUTPUT_VARIABLE LIBSTDCPLUSPLUS
+RESULT_VARIABLE RESULT)
+endif()
+string(REGEX REPLACE \n LIBSTDCPLUSPLUS ${LIBSTDCPLUSPLUS})
+if(RESULT MATCHES 0 AND LIBSTDCPLUSPLUS)
+ message(STATUS Linking with static libstdc++:\n ${LIBSTDCPLUSPLUS})
+ file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/staticlib)
+ execute_process(COMMAND ${CMAKE_COMMAND} -E remove
+${CMAKE_BINARY_DIR}/staticlib/libstdc++.a)
+ if(MINGW)
+execute_process(COMMAND ${CMAKE_COMMAND} -E copy
+ ${LIBSTDCPLUSPLUS} ${CMAKE_BINARY_DIR}/staticlib/libstdc++.a)
+ else()
+execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink
+ ${LIBSTDCPLUSPLUS} ${CMAKE_BINARY_DIR}/staticlib/libstdc++.a)
+ endif()
+ set(CMAKE_EXE_LINKER_FLAGS
+${CMAKE_EXE_LINKER_FLAGS} -L${CMAKE_BINARY_DIR}/staticlib)
+ set(CMAKE_SHARED_LINKER_FLAGS
+${CMAKE_SHARED_LINKER_FLAGS} -L${CMAKE_BINARY_DIR}/staticlib)
+else()
+ message(WARNING Cannot find static libstdc++. TigerVNC will depend on
dynamic libstdc++.)
+endif()
+set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -static-libgcc)
+set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -static-libgcc)
+set(CMAKE_SHARED_LINKER_FLAGS
+ ${CMAKE_SHARED_LINKER_FLAGS} -static-libgcc)
+ endif()
+endif()
+
###
# functions
include(CheckFunctionExists)
--
1.8.1.3
From bf06cdf83375c11a47bddc3683143b3e2c0fdfcb Mon Sep 17 00:00:00 2001
From: DRC informat...@virtualgl.org
Date: Tue, 26 Feb 2013 03:38:45 -0600
Subject: [PATCH 2/4] Fl_cocoa.mm depends on some Carbon functions, so we need
to include that framework.
---
CMakeLists.txt | 2
Re: [Tigervnc-devel] GPLv3 (and new release)
On 2/15/13 3:38 AM, Pierre Ossman wrote: But GPLv2 is broken, that's the point. Instead of me trying to reiterate things, I'll just point to FSF's page on the matter: http://www.gnu.org/licenses/quick-guide-gplv3.html We've been through this before. FSF thinks GPL v2 is broken, and Linus thinks GPL v3 is broken. You can choose your own religion on the matter, but I don't think everything that either party says should be considered gospel, personally. The FSF wrote the license, so of course they're going to be in favor of it. I will refer you to my previous response on the matter: https://sourceforge.net/mailarchive/message.php?msg_id=21930606 I look at this from a risk management point of view. The chances of someone abusing the GPL v2 in such a way that the GPL v3 would protect against it are miniscule. The chances of isolating TigerVNC from the rest of the VNC community by upgrading its license are, on the other hand, about 100%. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Migration to Allura
This is a roll-up of the relevant Allura code viewer features/fixes that I believe are necessary for SF to address in order to provide an environment as usable as ViewVC. If you have a SF account, please consider voting these up so we can get SourceForge's attention. Whenever a user clicks on the Code button, use HEAD as the default repository view rather than a sticky revision: https://sourceforge.net/p/allura/tickets/5120/ Provide a means of viewing in-repository static HTML and TXT files directly in the browser: https://sourceforge.net/p/allura/tickets/5772/ Provide more information (commit time, full commit message, file size, download/view links, etc.) in history view: https://sourceforge.net/p/allura/tickets/5773/ Allow diffing between arbitrary revisions in the history view: https://sourceforge.net/p/allura/tickets/4929/ Provide one-click access to history view of a file from directory view: https://sourceforge.net/p/allura/tickets/5774/ Provide a copied from link for files that have been renamed/moved: https://sourceforge.net/p/allura/tickets/5775/ -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[5031] trunk/BUILDING.txt
Why not break the shell script out into a separate file?
On 1/22/13 2:11 AM, astr...@users.sourceforge.net wrote:
Revision: 5031
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5031view=rev
Author: astrand
Date: 2013-01-22 08:11:05 + (Tue, 22 Jan 2013)
Log Message:
---
The recommended FLTK version is now 1.3.2. This means that several
patches are no longer necessary. Also, provide a shell script to
download and apply all patches.
Modified Paths:
--
trunk/BUILDING.txt
Modified: trunk/BUILDING.txt
===
--- trunk/BUILDING.txt2013-01-22 08:08:10 UTC (rev 5030)
+++ trunk/BUILDING.txt2013-01-22 08:11:05 UTC (rev 5031)
@@ -9,7 +9,7 @@
-- CMake (http://www.cmake.org) v2.8 or later
--- FLTK 1.3.0
+-- FLTK 1.3.2
* Must be a patched snapshot to get full functionality
* See Building FLTK below.
@@ -88,55 +88,55 @@
with plain 1.3.0, to get full functionality and the best behaviour you
need to build a patched version:
-1. Check out FLTK 1.3.0r9619 using Subversion:
-$ svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3 -r 9619
fltk-1.3.0r9619
+1. Check out FLTK 1.3.2 using Subversion:
+$ svn co http://svn.easysw.com/public/fltk/fltk/tags/release-1.3.2 fltk-1.3.2
-2. For full functionality, apply these patches:
+2. For full functionality, apply patches. Here's a shell script to do
+that:
-# Support horizontal mouse wheel
-# http://www.fltk.org/str.php?L2644
-$ patch -p1 fltk-1.3.x-hwheel.patch
+#!/bin/bash
+set -e
+apply_patch()
+{
+rm -f $2
+wget http://www.fltk.org/strfiles/$1/$2
+patch -p1 $2
+}
-# Incorrect resize handling
-# http://fltk.org/str.php?L2859
-$ patch -p1 fltk-1.3.x-resize-expose.patch
-
# Export dead key information from FLTK to the apps
# http://www.fltk.org/str.php?L2599
-$ patch -p1 fltk-1_v4.3.x-keyboard-x11.patch
-$ patch -p1 fltk-1_v4.3.x-keyboard-win32.patch
-$ patch -p1 fltk-1_v6.3.x-keyboard-osx.patch
+apply_patch 2599 fltk-1_v4.3.x-keyboard-x11.patch
+apply_patch 2599 fltk-1_v4.3.x-keyboard-win32.patch
+apply_patch 2599 fltk-1_v6.3.x-keyboard-osx.patch
# Notify applications of changes to the clipboard
# http://www.fltk.org/str.php?L2636
-$ patch -p1 fltk-1_v2.3.x-clipboard.patch
-$ patch -p1 fltk-1_v2.3.x-clipboard-x11.patch
-$ patch -p1 fltk-1_v4.3.x-clipboard-xfixes.patch
-$ patch -p1 fltk-1_v3.3.x-clipboard-win32-fix.patch
-$ patch -p1 fltk-1_v2.3.x-clipboard-win32.patch
-$ patch -p1 fltk-1_v2.3.x-clipboard-osx.patch
-$ patch -p0 fltk-xfixes-xcursor-cmake.2.patch
+apply_patch 2636 fltk-1.3.x-clipboard.patch
+apply_patch 2636 fltk-1_v4.3.x-clipboard-x11.patch
+apply_patch 2636 fltk-1_v3.3.x-clipboard-win32-fix.patch
+apply_patch 2636 fltk-1_v2.3.x-clipboard-win32.patch
+apply_patch 2636 fltk-1_v2.3.x-clipboard-osx.patch
# Ability to convert a Fl_Pixmap to a Fl_RGB_Image
# http://www.fltk.org/str.php?L2659
-$ patch -p1 fltk-1_v2.3.x-pixmap.patch
+apply_patch 2659 pixmap_v2.patch
# Support for custom cursors
# http://www.fltk.org/str.php?L2660
-$ patch -p1 fltk-1_v4.3.x-cursor.patch
+apply_patch 2660 fltk-1_v4.3.x-cursor.patch
# Improve modality interaction with WM
# http://www.fltk.org/str.php?L2802
-$ patch -p1 fltk-1_v2.3.0-modal.patch
+apply_patch 2802 fltk-1_v2.3.0-modal.patch
# Window icons
# http://www.fltk.org/str.php?L2816
-$ patch -p1 fltk-1_v2.3.0-icons.patch
+apply_patch 2816 fltk-1_v3.3.0-icons.patch
# Multihead
# http://fltk.org/str.php?L2860
-$ patch -p1 fltk-1.3.x-screen_num.patch
-$ patch -p1 fltk-1_v2.3.x-multihead.patch
+apply_patch 2860 fltk-1.3.x-screen_num.patch
+apply_patch 2860 fltk-1_v3.3.x-multihead.patch
3. Use CMake to build FLTK using the same procedures described below for
building TigerVNC. The recipes in the Build Recipes section also
apply.
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Tigervnc-commits mailing list
tigervnc-comm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-commits
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts.
Re: [Tigervnc-devel] [ tigervnc-Feature Request Tracker-3552744 ] FLTK Viewer: reinstate -via functionality
I was uncomfortable with libssh because, under the hood, it's going to require OpenSSL. TigerVNC is already difficult to build and has really become more the province of O/S distributors because of its onerous build requirements. I'm the guy who used to generate project binaries, and yet I had difficulty building the code in trunk. Using OpenSSL isn't such a big deal it you're releasing TigerVNC for a specific platform and can take advantage of the system libraries. But it creates difficulties when trying to create a cross-platform version of TigerVNC. But given that I'm no longer with the project and no longer generating cross-platform project binaries, it really doesn't matter to me anymore what you guys do. I'm just offering up the suggestion that adding a dependency on libssh may make the build even more onerous and further turn off potential contributors. Given that Cendio is the only active developer, the only things that get tested are things they care about, so libssh functionality would have to be maintained by someone else. Personally, I prefer -via calling an external SSH executable on Un*x and Windows, and that's the route we're taking with TurboVNC. We supply a build of PLink with the vncviewer executable, but the feature (once completed) will allow you to override that with, for instance, Cygwin OpenSSH. On Jan 20, 2013, at 2:37 PM, Eric Stadtherr estadth...@gmail.com wrote: All, My project uses the -via capability extensively in our display architecture on Red Hat, so I'm very interested in ensuring that functionality persists in the new viewer. I've worked on the -via code in the old viewer before, and am very familiar with how it works. I'm more than willing to add the feature to the new viewer, but I want to make sure I'm not duplicating effort. Is anyone else working on this capability? If I go ahead with it, I could implement it a couple different ways: spawn an ssh executable as a child with a port tunnelled to the remote VNC port (the way the old viewer did it). This works fine on Unix (assuming the TCP port is handled correctly), but isn't really portable to Windows since there isn't a standard ssh command line tool. integrate SSH as a library (such as with the OpenSSH library). I actually did this to the old viewer, but DRC was uncomfortable adding another library dependency at the time. That's the drawback - another 3rd party library dependency. I'd welcome everyone's opinion on approaches. Thanks, Eric On 09/17/2012 02:37 PM, Robert Goley wrote: The only full featured viewer for TigerVNC is currently the java viewer. It has the SSH tunneling and TLS capabilities. The command line is slightly changed but a quick script could be written to pass variables using the old syntax. Hope this gives you a better work around than sticking with the older viewer. Robert On 09/17/2012 03:59 PM, SourceForge.net wrote: Feature Request Tracker item #3552744, was opened at 2012-07-31 12:40 Message generated for change (Comment added) made by ikelos You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126849aid=3552744group_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: FLTK viewer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Havin_it (havinit) Assigned to: Pierre Ossman (ossman_) Summary: FLTK Viewer: reinstate -via functionality Initial Comment: I note the discussion of this issue in #3429667, so this is just putting on record that someone is interested in seeing the feature return. As a sidenote, the vncviewer manpage (on Gentoo, user-submitted 1.2.0 ebuild) currently still lists the -via option. If the feature does return, I submit that the description could do with some clarification on how to correctly use it for complex use-cases, e.g. non-standard SSH or local/remote bound VNC ports, or specifying the username on the gateway host. I had to resort to a lot of googling and trial-and-error for my use-case (which combines all of the above!) ... before finally learning the feature wasn't actually implemented :/ -- Comment By: Mike Auty (ikelos) Date: 2012-09-17 12:59 Message: It's a shame this isn't a priority at Cendio. Ever since the auth bypass in realvnc, I assume most users deny access to the server apart from localhost, and therefore rely on the via option for quick and easy access to their servers. I guess I'll be staying at 1.1.0, since the changes won't likely have as much of an effect on my productivity as removing the via option will, which is a pity... -- You can respond by visiting: https
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On 1/16/13 3:12 AM, Peter Åstrand wrote:
Sure, but we don't have the details. It's not very useful to submit a
bug report that says it fails on some machines but not mine :-)
Didn't I just supply the details? And a fix?
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
Ok, that makes sense. Would it be possible for you to extend the patch
in this way? We do not build FLTK with CMake.
Well, if you don't build FLTK with CMake, then why does the documented
procedure for building FLTK (in BUILDING.txt) require CMake? This is
the basic problem I've been complaining about all along-- a fundamental
disconnect between what users of the open source code are expected to do
and what Cendio actually tests. In other words, you guys need to eat
your own dog food.
Extending the patch is definitely not a priority for me, but it would
probably take you or Pierre all of 5 minutes.
I prefer vncviewer/CMakeLists.txt. In our build, we have actually added
this:
if(UNIX AND NOT APPLE)
# Needed to load icon files
target_link_libraries(vncviewer -Wl,-Bstatic ${FLTK_IMAGES_LIBRARY}
png -Wl,-Bdynamic)
endif()
So add it to everyone's build, then.
Yes, we should make it as easy as possible. Shouldn't be necessary to
tweak FLTK though; linking libgcc and libstdc++ statically can be done
from the TigerVNC make files.
Try it. I think you'll find, as I did, that it doesn't work that way.
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On 1/16/13 6:08 AM, Peter Åstrand wrote: On Wed, 16 Jan 2013, DRC wrote: On 1/16/13 3:12 AM, Peter Åstrand wrote: Sure, but we don't have the details. It's not very useful to submit a bug report that says it fails on some machines but not mine :-) Didn't I just supply the details? And a fix? Yes, a fix, but I don't understand on which machines this is failing, or why. (a) Does it matter? A simple examination of the patch reveals that it does the right thing. If you set CMAKE_REQUIRED_LIBRARIES for the purposes of checking whether a function exists, you should *always* unset it afterwards. (b) OS X, and I don't know exactly why, and I don't exactly care. Probably because libpng isn't in /usr/lib on that platform. All I know is that it failed because the CMakeLists.txt file was not doing the right thing, and making it do the right thing fixed the failure. Really, it's much better if you communicate with the FLTK upstream directly. We have no special communication channels. No time to do so, and not my problem. Well, if you don't build FLTK with CMake, then why does the documented procedure for building FLTK (in BUILDING.txt) require CMake? I think this was my mistake. If I remember correctly, I assumed that we were also building FLTK with CMake and didn't check this. One advantage though is that it imposes fewer dependencies. For example, if you are building on Windows, I suppose building with Autotools requires you to install more packages(?). Don't get me wrong. I'm not suggesting that you switch to autotools. We had that conversation years ago-- autotools is a non-starter for Windows builds. Requiring it as part of the TigerVNC build procedure will eliminate almost all Windows developers from your community. What I am suggesting is that you actually test what you recommend to the open source community. Had you ever tried to build FLTK with CMake on all of the platforms you purport to support, you would have discovered these issues yourselves. I think it's unfortunate that FLTK is trying to support two different build systems. My experience is that this never works. Accordingly, I have opened up http://www.fltk.org/str.php?L2916 . Anyway, in the mean time, the question is if we should start building FLTK with CMake, or if we should change the documentation to recommend Autotools instead? When looking in the FLTK repository, it seems to me that the CMake build system gets less attention than the Autotools one, and is constantly lagging behind. For example, configure.in says we are at FLTK 1.3.1, while CMakeLists.txt says 1.3.0. There are several bug reports of that the CMake files are out of sync, for example http://www.fltk.org/str.php?L2088 . My suggestion is therefore that we start recommending building FLTK with Autotools instead. Ok with everyone? sigh No. Again, goes back to the eat your own dog food thing. If you ever actually tried to build TigerVNC on a real Windows platform, you would understand why most things you have done to make it easier on yourself as a Linux developer have made it harder on Windows developers. As far as everyone, when was the last time anyone but me actually spoke up regarding one of these issues? -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On 1/16/13 6:56 AM, Peter Åstrand wrote: The two major sponsors of the TigerVNC project are Cendio and Red Hat, and we both are focusing on Linux, so it's quite natural that we favour build systems that works good on Linux. Few if any people have the resources to test things on more than a handful of platforms. We are building and testing TigerVNC for all supported platforms (Linux, Solaris, Windows, Mac), but with only one build system (cross compilation under Linux). We are not building on any version of Windows, Solaris, or Mac OS X. We don't have the resources to do that. Sorry. If you want, I can see if we can switch our internal FLTK build to CMake instead of Autotools, but I'm not sure what else we can do. That would be helpful, yes. BTW, is Red Hat even using a recent version of TigerVNC? Last I checked, Fedora was still on 1.1.0. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Build issues in trunk w/ some fixes suggestions
On 1/7/13 4:25 AM, Peter Åstrand wrote:
(3) CMakeLists.txt in the FLTK build system needs to be patched as
follows:
Otherwise, it will try to add -lpng to all of the subsequent function
checks, which causes them to fail on some machines (including mine.)
Have you reported this to the FLTK folks? Again, probably makes sense to
wait with further debugging on this until we have 1.3.2.
No, because it's frankly not my problem, and it would be a lot quicker
for you and Pierre, who have inroads into the FLTK project, to report
it. I am assuming that, if you are interested in making the TigerVNC
build user-friendly, you will want to follow these suggestions. I've
already worked around the issues in my own local build. I submitted
these issues to you both as a favor and so users who inevitably try to
build TigerVNC from trunk and come up with the same issues will be able
to google for them. I build TigerVNC only for reference, so I am not
getting paid to solve any broader issues with that code base or with FLTK.
(4) Fluid build fails on Mac using CMake unless CMakeLists.txt in the
FLTK build system is patched as follows:
As point 3), I think.
No, because this is a bug introduced by the patches that Cendio made to
FLTK. All I'm suggesting is to extend fltk-1_v6.3.x-keyboard-osx.patch
so that it adds '-framework Carbon' in the CMake build system the same
way it already does in the autotools build system. Don't see why you
have to wait for 1.3.2 for that, since this is not an upstream problem.
It's a problem created by an FLTK patch that was specifically made for
the purposes of TigerVNC.
(6) The TigerVNC build will fail unless I patch TigerVNC's
CMakeLists.txt as follows:
--- CMakeLists.txt(revision 5021)
+++ CMakeLists.txt(working copy)
@@ -265,6 +265,7 @@
if(X11_Xcursor_FOUND)
set(FLTK_LIBRARIES ${FLTK_LIBRARIES} ${X11_Xcursor_LIB})
endif()
+ set(FLTK_LIBRARIES ${FLTK_LIBRARIES} png)
endif()
This goes away when building FLTK with -DOPTION_USE_SYSTEM_LIBPNG=0, but
distribution vendors will run into this problem, since they'll probably
want to use the system libpng. Since the patch above does no harm when
using FLTK's internal PNG library, I would suggest going ahead and
applying it to TigerVNC.
Shouldn't this go into vncviewer/CMakeLists.txt instead?
Effectively, it probably doesn't matter either way, since FLTK is only
used when building vncviewer, but since libpng is a dependency
introduced by FLTK, it made sense to me to include it in FLTK_LIBRARIES.
But either way you want.
(7) Building FLTK using MinGW is problematic because of the dependency
on the libgcc and libstdc++ DLL's. These dependencies are automatically
Yes, this is somewhat problematic, but as you point out, this is really
a problem with FLTK rather than TigerVNC.
You keep saying that, but I'll say again like I said before-- this is
effectively a regression in the TigerVNC build, because this problem did
not exist in the 1.2 build by virtue of the fact that FLTK was being
built in tree. If a user wants to build a workable Windows version of
TigerVNC from trunk, they currently need to seriously hack the FLTK
build system like I did. But whatever. If you want to throw the most
popular client platform under the bus, then that's your decision to
make. Just understand that, the more frustrating you make TigerVNC, the
more you drive users away, and you should ask yourself where those users
are being driven to and why I have such intimate knowledge of their
frustrations with TigerVNC.
(8) You are using ImageMagick to generate tigervnc.png. Of course
ImageMagick is not available on Windows, so the Windows build fails. I
mean, seriously, check the PNG files into SVN. They're all of, what, 2
kilobytes?!
I have no objections to checking in the PNG files, but is this really
enough? Have you tried running the build with the PNG files already in
place? My guess is that CMake and the make files will still look for
convert etc and fail if it's not available. We would probably need
some kind of logic that only looks for convert if the PNG files needs
remake.
The problem is that Windows has a convert executable that's part of
the operating system, but of course it is not the right convert
executable. On Linux, if ImageMagick is not installed, the build fails
cryptically with cannot find /usr/bin/convert or something like that.
Rather than argue, I checked in a patch (5024) that I have verified to
fix the issue and build correctly on all platforms. If you don't like
it, back it out. But if you choose to keep using ImageMagick to
generate the icons, then you need to (a) document that as a build
dependency for Linux/Unix platforms and (b) add logic to
media/CMakeLists.txt to ensure that it doesn't try to build the icons on
Windows.
--
Master Visual Studio,
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[5024] trunk/media
I should add that, with this patch, the build system can still be used
to regenerate the in-tree copies of the icons, if for any reason they
need updating. Simply
cd media
make clean
make icons
On 1/7/13 4:24 PM, dcomman...@users.sourceforge.net wrote:
Revision: 5024
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=5024view=rev
Author: dcommander
Date: 2013-01-07 22:24:01 + (Mon, 07 Jan 2013)
Log Message:
---
Check the generated icons into the build tree. This solves a couple of
issues: (1) it eliminates the build dependency on ImageMagick, which was not
documented and which creates a hard-to-diagnose build failure on platforms on
which it isn't available, and (2) the build was completely broken on Windows,
because Windows has a convert.exe program that is part of the operating
system, and the TigerVNC build system was finding this and attempting to use
it to generate the icons.
Modified Paths:
--
trunk/media/CMakeLists.txt
Added Paths:
---
trunk/media/icons/tigervnc_16.png
trunk/media/icons/tigervnc_22.png
trunk/media/icons/tigervnc_24.png
trunk/media/icons/tigervnc_32.png
trunk/media/icons/tigervnc_48.png
Modified: trunk/media/CMakeLists.txt
===
--- trunk/media/CMakeLists.txt2013-01-07 09:59:00 UTC (rev 5023)
+++ trunk/media/CMakeLists.txt2013-01-07 22:24:01 UTC (rev 5024)
@@ -1,18 +1,18 @@
set(ICON_FILES
- icons/tigervnc_16.png
- icons/tigervnc_22.png
- icons/tigervnc_24.png
- icons/tigervnc_32.png
- icons/tigervnc_48.png)
+ ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_16.png
+ ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_22.png
+ ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_24.png
+ ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_32.png
+ ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_48.png)
find_program(CONVERT_EXECUTABLE convert)
if(CONVERT_EXECUTABLE)
- add_custom_target(icons-target ALL DEPENDS ${ICON_FILES})
+ add_custom_target(icons DEPENDS ${ICON_FILES})
if(UNIX AND NOT APPLE)
foreach(SIZE 16 22 24 32 48)
- install(FILES ${CMAKE_CURRENT_BINARY_DIR}/icons/tigervnc_${SIZE}.png
+ install(FILES icons/tigervnc_${SIZE}.png
DESTINATION ${DATA_DIR}/icons/hicolor/${SIZE}x${SIZE}/apps
RENAME tigervnc.png)
endforeach()
@@ -21,34 +21,37 @@
endif()
endif()
-add_custom_command(OUTPUT icons COMMAND mkdir icons)
-
-add_custom_command(OUTPUT icons/tigervnc_16.png
+add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_16.png
COMMAND ${CONVERT_EXECUTABLE} -background transparent
-${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_16.svg icons/tigervnc_16.png
+${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_16.svg
+${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_16.png
DEPENDS icons ${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_16.svg
COMMENT Generating icons/tigervnc_16.png)
-add_custom_command(OUTPUT icons/tigervnc_22.png
+add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_22.png
COMMAND ${CONVERT_EXECUTABLE} -size 22x22 xc:none -gravity center
-background transparent
-${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg -composite
icons/tigervnc_22.png
+${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg -composite
+${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_22.png
DEPENDS icons ${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg
COMMENT Generating icons/tigervnc_22.png)
-add_custom_command(OUTPUT icons/tigervnc_24.png
+add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_24.png
COMMAND ${CONVERT_EXECUTABLE} -size 24x24 xc:none -gravity center
-background transparent
-${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg -composite
icons/tigervnc_24.png
+${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg -composite
+${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_24.png
DEPENDS icons ${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_20.svg
COMMENT Generating icons/tigervnc_24.png)
-add_custom_command(OUTPUT icons/tigervnc_32.png
+add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_32.png
COMMAND ${CONVERT_EXECUTABLE} -size 32x32 xc:none -gravity center
-background transparent
-${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_28.svg -composite
icons/tigervnc_32.png
+${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_28.svg -composite
+${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_32.png
DEPENDS icons ${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_28.svg
COMMENT Generating icons/tigervnc_32.png)
-add_custom_command(OUTPUT icons/tigervnc_48.png
+add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/icons/tigervnc_48.png
COMMAND ${CONVERT_EXECUTABLE} -size 48x48 xc:none -gravity center
-background transparent
-${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_42.svg -composite
icons/tigervnc_48.png
+${CMAKE_CURRENT_SOURCE_DIR}/tigervnc_42.svg
Re: [Tigervnc-devel] Migration to Allura
On a side note, if anyone knows of a Subversion thick client that has as rich a feature set as this, I'd like to know about it. I am not aware of one that allows you to view a history of a file or a tree in the way that ViewVC does. I really wish SourceForge would just keep ViewVC as an option. They seem to be going all Apple Maps on us here. On 11/27/12 2:09 AM, Peter Åstrand wrote: Thanks, I'm now subscribing to that ticket. So, do you (or anybody else) consider the limited ViewVC-replacement a show stopper for the Allura migration? I agree with you that this should really be fixed. OTOH, as a developer, you could use real Subversion clients instead to view this information. Several GUIs are available, in addition to the command line tools. And hopefully, the code viewer in Allura will be fixed eventually. My suggestion is thus that we proceed with the migration. Rgds, Peter On Mon, 26 Nov 2012, DRC wrote: I added a brief list of critical features that I think are missing from the new SVN viewer on this bug report: https://sourceforge.net/p/forge/site-support/480/ Since posting this, they have fixed (2) [apparently a bug] and addressed (4) with the new Browse Commits feature. However, the ability to pull up a revision history for just one file and diff between arbitrary revisions of that file is critical. You can follow links in the ticket above to get to about a dozen more tickets regarding user complaints about the new code viewer. On 11/21/12 9:26 AM, Peter Åstrand wrote: Oh, thanks for pointing this out. Can you describe more in detail what features are missing? Have you reported this to https://sourceforge.net/p/forge/site-support/ ? Rgds, Peter On Wed, 21 Nov 2012, DRC wrote: My main issue with the new platform at the moment is that they've replaced the repository browser. Instead of ViewVC, it's now their own version that, frankly, sucks. There are a lot of beta users, including me, complaining about this. I am hoping they address that issue or provide a ViewVC option before the new SF platform is released. I migrated libjpeg-turbo and have regretted it, because I use the online repo browser enough that not having a fully functional one has been an impediment. On Nov 21, 2012, at 3:45 AM, Peter Åstrand astr...@cendio.se wrote: Hi. As you perhaps know, Sourceforge is introducing a new platform called Allura. Old projects can quite easily migrate. There are several advantages of doing so: * SF want projects to migrate, and they are not working on the old framework any longer. Support cases are often closed with wont fix. * The new interface is nicer and should be easier to use. More details about Allura can be found here: https://sourceforge.net/p/allura/wiki/Features/ I think we should proceed with the migration to Allura, but if anyone objects, please say so. If there are no objections, I will do the migration 2012-11-29. Please note that the SVN URL will be changed. Rgds, --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers
Re: [Tigervnc-devel] Migration to Allura
I added a brief list of critical features that I think are missing from the new SVN viewer on this bug report: https://sourceforge.net/p/forge/site-support/480/ Since posting this, they have fixed (2) [apparently a bug] and addressed (4) with the new Browse Commits feature. However, the ability to pull up a revision history for just one file and diff between arbitrary revisions of that file is critical. You can follow links in the ticket above to get to about a dozen more tickets regarding user complaints about the new code viewer. On 11/21/12 9:26 AM, Peter Åstrand wrote: Oh, thanks for pointing this out. Can you describe more in detail what features are missing? Have you reported this to https://sourceforge.net/p/forge/site-support/ ? Rgds, Peter On Wed, 21 Nov 2012, DRC wrote: My main issue with the new platform at the moment is that they've replaced the repository browser. Instead of ViewVC, it's now their own version that, frankly, sucks. There are a lot of beta users, including me, complaining about this. I am hoping they address that issue or provide a ViewVC option before the new SF platform is released. I migrated libjpeg-turbo and have regretted it, because I use the online repo browser enough that not having a fully functional one has been an impediment. On Nov 21, 2012, at 3:45 AM, Peter Åstrand astr...@cendio.se wrote: Hi. As you perhaps know, Sourceforge is introducing a new platform called Allura. Old projects can quite easily migrate. There are several advantages of doing so: * SF want projects to migrate, and they are not working on the old framework any longer. Support cases are often closed with wont fix. * The new interface is nicer and should be easier to use. More details about Allura can be found here: https://sourceforge.net/p/allura/wiki/Features/ I think we should proceed with the migration to Allura, but if anyone objects, please say so. If there are no objections, I will do the migration 2012-11-29. Please note that the SVN URL will be changed. Rgds, --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Migration to Allura
My main issue with the new platform at the moment is that they've replaced the repository browser. Instead of ViewVC, it's now their own version that, frankly, sucks. There are a lot of beta users, including me, complaining about this. I am hoping they address that issue or provide a ViewVC option before the new SF platform is released. I migrated libjpeg-turbo and have regretted it, because I use the online repo browser enough that not having a fully functional one has been an impediment. On Nov 21, 2012, at 3:45 AM, Peter Åstrand astr...@cendio.se wrote: Hi. As you perhaps know, Sourceforge is introducing a new platform called Allura. Old projects can quite easily migrate. There are several advantages of doing so: * SF want projects to migrate, and they are not working on the old framework any longer. Support cases are often closed with wont fix. * The new interface is nicer and should be easier to use. More details about Allura can be found here: https://sourceforge.net/p/allura/wiki/Features/ I think we should proceed with the migration to Allura, but if anyone objects, please say so. If there are no objections, I will do the migration 2012-11-29. Please note that the SVN URL will be changed. Rgds, --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://cendio.com Teknikringen 8http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Proposed patch to support rfbTightNoZlib
The attached adds support for the unofficial rfbTightNoZlib extension
used by the TurboVNC Server to transmit Raw, indexed color, and mono
subrectangles without Zlib compression. This prevents the TigerVNC
Viewer from crashing if the user attempts to select Compress level 0
while connected to a TurboVNC server.
DRC
Index: common/rfb/tightDecode.h
===
--- common/rfb/tightDecode.h(revision 4999)
+++ common/rfb/tightDecode.h(working copy)
@@ -1,6 +1,6 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights Reserved.
* Copyright 2004-2005 Cendio AB.
- * Copyright (C) 2011 D. R. Commander. All Rights Reserved.
+ * Copyright (C) 2011-2012 D. R. Commander. All Rights Reserved.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -70,6 +70,12 @@
comp_ctl = 1;
}
+ bool readUncompressed = false;
+ if ((comp_ctl rfbTightNoZlib) == rfbTightNoZlib) {
+comp_ctl = ~(rfbTightNoZlib);
+readUncompressed = true;
+ }
+
// Fill compression type.
if (comp_ctl == rfbTightFill) {
PIXEL_T pix;
@@ -138,7 +144,7 @@
int dataSize = r.height() * rowSize;
int streamId = -1;
rdr::InStream *input;
- if (dataSize TIGHT_MIN_TO_COMPRESS) {
+ if (dataSize TIGHT_MIN_TO_COMPRESS || readUncompressed) {
input = is;
} else {
int length = is-readCompactLength();
@@ -147,6 +153,9 @@
input = zis[streamId];
}
+ if (readUncompressed dataSize = TIGHT_MIN_TO_COMPRESS)
+dataSize = is-readCompactLength();
+
// Allocate netbuf and read in data
rdr::U8 *netbuf = new rdr::U8[dataSize];
if (!netbuf) {
Index: common/rfb/TightDecoder.h
===
--- common/rfb/TightDecoder.h (revision 4999)
+++ common/rfb/TightDecoder.h (working copy)
@@ -1,5 +1,5 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights Reserved.
- * Copyright (C) 2011 D. R. Commander. All Rights Reserved.
+ * Copyright (C) 2011-2012 D. R. Commander. All Rights Reserved.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -71,6 +71,7 @@
const unsigned int rfbTightFill = 0x08;
const unsigned int rfbTightJpeg = 0x09;
const unsigned int rfbTightMaxSubencoding = 0x09;
+ const unsigned int rfbTightNoZlib = 0x0A;
// Filters to improve compression efficiency
const unsigned int rfbTightFilterCopy = 0x00;
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Proposed patch to support rfbTightNoZlib
On 10/2/12 5:21 AM, Pierre Ossman wrote: The attached adds support for the unofficial rfbTightNoZlib extension used by the TurboVNC Server to transmit Raw, indexed color, and mono subrectangles without Zlib compression. This prevents the TigerVNC Viewer from crashing if the user attempts to select Compress level 0 while connected to a TurboVNC server. The principle is reasonable, but is this an officially allocated number? You seem to be using it as a bit, even though it isn't a single bit. I don't see how that can work. fill | nozlib == 0x08 | 0x0A = 0x0A. So masking off nozlib does not give you back fill, but 0x00. And I see no code for telling the server that the client supports the extension. Well, bear in mind that this extension has been in use for 5 years quite successfully in TurboVNC, so it definitely works correctly. It is also now in libvncserver, so there is at least de facto adoption of it. No, it isn't officially allocated, but there are no conflicts of which I'm aware (see below regarding rfbTightPNG.) From rfbproto.h: /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Tight Encoding. * *-- The first byte of each Tight-encoded rectangle is a compression control * byte. Its format is as follows (bit 0 is the least significant one): * * bit 0:if 1, then compression stream 0 should be reset; * bit 1:if 1, then compression stream 1 should be reset; * bit 2:if 1, then compression stream 2 should be reset; * bit 3:if 1, then compression stream 3 should be reset; * bits 7-4: if 1000 (0x08), then the compression type is fill, * if 1001 (0x09), then the compression type is jpeg, * if 1010 (0x0A), then the compression type is basic and no * Zlib compression was used, * if 1110 (0x0E), then the compression type is basic, no Zlib * compression was used, and a filter id byte follows this * byte, * if 0xxx, then the compression type is basic and Zlib * compression was used, * values greater than 1010 are not valid. * * If the compression type is basic and Zlib compression was used, then bits * 6..4 of the compression control byte (those xxx in 0xxx) specify the * following: * * bits 5-4: decimal representation is the index of a particular zlib * stream which should be used for decompressing the data; * bit 6: if 1, then a filter id byte is following this byte. As you can see, the protocol is designed such that some constants act as bit masks and some constants act as enumerators (that wasn't my design-- it was Constantin's.) Since we've already right-shifted comp_ctl by 4, bits 7-4 are now in bits 3-0, but I'll still refer to them as bits 7-4 to be consistent with the above. The decoder checks whether comp_ctl 0x0A == 0x0A, which it only will be if comp_ctl is 0x0A or 0x0E. If it's equal to rfbTightFill or rfbTightJpeg, then the test is false, but no worries, because Zlib is irrelevant for those two subencoding types. If comp_ctl is 0x0A or 0x0E, we mask off bits 5 and 7, so we're left with bit 6 to indicate whether a filter ID byte follows (filter ID's are used with indexed color or with the obsolete gradient encoding. If a filter ID is not present, then that means the subrectangle uses raw subencoding.) There is no code to tell the server that the client supports the extension. The TurboVNC Server will always use rfbTightNoZlib when it receives a request for compression level 0 without JPEG. Other servers, such as the TigerVNC Server, don't support the extension, but with this patch, the viewer can now decode streams from both. Given that compression level 0 is not even documented with most VNC viewers (including TigerVNC), this is almost a hidden mode with anything but the TurboVNC Viewer. There are a significant number of users in the TurboVNC community, however, who take advantage of TurboVNC's Lossless Tight mode (and yes, I know that's an oxymoron) on fast networks, particularly if they are using it to transmit pixels internally from a Linux server to a Citrix server that does the final image compression. In those cases, JPEG can fool Citrix's interframe differencing engine, and it also adds unnecessary CPU overhead. TigerVNC has never used the TightVNC capabilities registry, which would be a great way to inform the client and server of their support of this extension (not to mention others.) When integrating the TurboVNC encoder with libvncserver, we discovered that rfbTightPNG (the enumerator for the experimental PNG subencoding type) is also 0x0A. It acts very much like rfbTightJpeg and rfbTightFill. However, TightPNG is a different encoding type from Tight, so there is no conflict, since rfbTightNoZlib is used only with rfbEncodingTight and rfbTightPNG is used only
[Tigervnc-devel] Proposed patch to support rfbTightNoZlib
The attached adds support for the unofficial rfbTightNoZlib extension
used by the TurboVNC Server to transmit Raw, indexed color, and mono
subrectangles without Zlib compression. This prevents the TigerVNC
Viewer from crashing if the user attempts to select Compress level 0
while connected to a TurboVNC server.
DRC
Index: common/rfb/tightDecode.h
===
--- common/rfb/tightDecode.h(revision 4999)
+++ common/rfb/tightDecode.h(working copy)
@@ -1,6 +1,6 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights Reserved.
* Copyright 2004-2005 Cendio AB.
- * Copyright (C) 2011 D. R. Commander. All Rights Reserved.
+ * Copyright (C) 2011-2012 D. R. Commander. All Rights Reserved.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -70,6 +70,12 @@
comp_ctl = 1;
}
+ bool readUncompressed = false;
+ if ((comp_ctl rfbTightNoZlib) == rfbTightNoZlib) {
+comp_ctl = ~(rfbTightNoZlib);
+readUncompressed = true;
+ }
+
// Fill compression type.
if (comp_ctl == rfbTightFill) {
PIXEL_T pix;
@@ -138,7 +144,7 @@
int dataSize = r.height() * rowSize;
int streamId = -1;
rdr::InStream *input;
- if (dataSize TIGHT_MIN_TO_COMPRESS) {
+ if (dataSize TIGHT_MIN_TO_COMPRESS || readUncompressed) {
input = is;
} else {
int length = is-readCompactLength();
@@ -147,6 +153,9 @@
input = zis[streamId];
}
+ if (readUncompressed dataSize = TIGHT_MIN_TO_COMPRESS)
+dataSize = is-readCompactLength();
+
// Allocate netbuf and read in data
rdr::U8 *netbuf = new rdr::U8[dataSize];
if (!netbuf) {
Index: common/rfb/TightDecoder.h
===
--- common/rfb/TightDecoder.h (revision 4999)
+++ common/rfb/TightDecoder.h (working copy)
@@ -1,5 +1,5 @@
/* Copyright (C) 2000-2003 Constantin Kaplinsky. All Rights Reserved.
- * Copyright (C) 2011 D. R. Commander. All Rights Reserved.
+ * Copyright (C) 2011-2012 D. R. Commander. All Rights Reserved.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -71,6 +71,7 @@
const unsigned int rfbTightFill = 0x08;
const unsigned int rfbTightJpeg = 0x09;
const unsigned int rfbTightMaxSubencoding = 0x09;
+ const unsigned int rfbTightNoZlib = 0x0A;
// Filters to improve compression efficiency
const unsigned int rfbTightFilterCopy = 0x00;
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] rh692048 patch
On 9/6/12 9:11 AM, Adam Tkac wrote: In my opinion the best will be to automatically add VeNCrypt only when user explicitly selects some VeNCrypt subtype (TLS*/X509*). If no VeNCrypt subtype is selected, then default should be VncAuth, not VeNCrypt,VncAuth, which is default now. I concur. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] revert r4220 to fix bug #3415308
On 7/13/12 3:09 AM, Pierre Ossman wrote: I dived into vncHooks and xserver sources and attached patch should fix both screen artefacts and XDrawArc crashes. It reverts r4220 and fixes vncHooksFillSpans hook which used wrong clip pointer. -Inf Hooking pixmaps is just asking for problems. You'll be using the pixmap's coordinates for tracking changes, which makes absolutely no sense there is no fundamental connection to screen coordinates (like there is for windows). We need to find a proper way to deal with this specific case (borders). It might be that it's impossible to hook the actual drawing itself, but then we'll have to look at its triggering conditions instead and duplicate some of the border logic. E.g. hooking expose events and checking window flags. Maybe I'm missing something, but isn't the goal to hook only drawing commands that actually produce visible information? That being the case, isn't the relevant data already being hooked when the pixmap gets copied to the window using XCopyArea()? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] revert r4220 to fix bug #3415308
On 7/3/12 3:42 PM, Brian Hinz wrote: I'm not sure if this means anything to you, but I found that if I set 'AlwaysSetDeferUpdateTimer=1' then outline boxes are partially drawn and damaged regions are sometimes partially redrawn. The location and extent to which the lines are drawn is seemingly random, but it's never complete (except when a screen refresh is requested). Also, the value of 'DeferUpdate' does not seem to make any difference. Any thoughts? Is there any chance that this is a viewer issue? When you mentioned partial updates, that brought to mind 3531487. Just a shot in the dark. https://sourceforge.net/tracker/?func=detailaid=3531487group_id=254363atid=1126848 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [ tigervnc-Bug Tracker-3531487 ] Double buffering doesn't work properly in new viewer
On 6/5/12 1:51 AM, Peter Åstrand wrote: vncviewer already has many command line parameters. We shouldn't add another one unless it's absolutely necessary. It's better if things like these can be handled automatically. What you decide to do about it (if anything) is up to you. I'm just expressing that the 3D community definitely wants true double buffering, and such is not present in the current release of TigerVNC. The easiest way to fix it, even if it's just a short-term fix, is to add a new configuration parameter. Personally, I don't buy the argument that it's necessary to put a timeout on FBU's, and I'm not sure how you would go about automating such a thing. I certainly don't buy the argument that adding a new configuration parameter is such a big deal if it gives users an option for true double buffering. You're more or less trying to automate it already, and it isn't working, hence the bug report. However, none of that is my problem. I just filed the bug report as a courtesy. Talk amongst yourselves. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [ tigervnc-Bug Tracker-3531487 ] Double buffering doesn't work properly in new viewer
On 6/4/12 6:30 AM, Pierre Ossman wrote: However, I haven't examined the code closely to see why that timer is there. What seems to happen is that, whenever a rectangle is damaged, it triggers a timeout, and if the rectangle isn't drawn within 1/2 second, it gets drawn anyway, so if the frame is really slow to transmit, it will not be double buffered. The idea is to make sure that the viewer doesn't appear hung if the update is taking too long to come in. Tearing isn't nice, but locking up is worse. That said, the timeout could possibly be increased further. It just needs to be small enough to avoid users getting impatient and clicking/typing again, thinking the first attempt didn't really take. That depends on what type of app you're using. You have to remember that what qualifies as an update will vary from app to app. I have never seen an update take so long that the user would actually suspect that the viewer was hung, but even if that happened, it would only occur on a full-screen update. Full-screen updates are typically not going to happen except in video and 3D apps, and for those apps, the user is likely to prefer that the updates be drawn in tact. At minimum, I think you need to add a double buffering parameter which, when enabled, will cause the viewer to strictly wait until the end of the framebuffer update before repainting. We're not just talking about tearing. We're taking about ugly black rectangles that appear in the middle of the video or the 3D scene as it is animating. Regardless, though, the point is that the FLTK viewer cannot claim to support double buffering at the moment. It would be very easy to make it do so (a new parameter and a one-line code change.) Personally, I think the new parameter should be enabled by default, but if history is any indication, you're likely to disagree. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [ tigervnc-Bug Tracker-3531487 ] Double buffering doesn't work properly in new viewer
On 6/2/12 7:20 AM, Brian Hinz wrote: I have observed the black notch issue with the java viewer previously as well. If the call to paintImmediately in DesktopWindow.updateWindow is replaced with repaint these notches are observed. Using repaint rather than paintImmediately allows swing to defer drawing until it can collapse multiple updates into a single paint operation. I'm not sure how Fltk handles painting, but if it's deferring the actual screen updates in some similar manner then that could be the culprit. You're right. The issue exists in the 1.2.0 Java code but not in the latest from trunk, and paintImmediately() definitely seems to be the difference. It wouldn't surprise me if FLTK is doing something similar. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] new features
From my point of view (which is relevant because the new TurboVNC Java Viewer and the TigerVNC 1.2 Java Viewer are about to share a very similar code base), the ability to do -via and basic SSH tunneling within the Java viewer will be very useful, but the ability to forward arbitrary ports probably won't be for us. We've discussed this in the context of the TigerVNC C client in the past, and while it is certainly possible, it would introduce some additional complexity, since the viewer would need to depend on libssh. In order to achieve the same performance that can already be achieved with an external SSH binary (through the -via feature), libssh would need to be built against OpenSSH rather than GnuTLS. It's not impossible, but it just creates yet another security layer, which makes an already difficult-to-build project even moreso. Mainly, the difficulty would be encountered on platforms like Windows, where there is no built-in OpenSSH library. The assumption is that, with most *nix systems, it would be the job of the distro maintainer to stay abreast of security fixes in their distribution-supplied versions of OpenSSH and GnuTLS. As far as one-time password support, that is a server-side feature. The client treats OTPs just like any other VNC password. On 4/2/12 12:28 PM, Robert Goley wrote: I support the SSH feature. It is a functionality that we have used for a long time to add printer sharing between the client and server. It makes the client function more like how RDP works in that regard. The combination of CUPS on the server and the fact that windows, linux and mac clients all support LPD makes this feature easy to use with one simple ssh remote port forward to the client's local LPD server port (515/tcp). We use a range of ports on the server that correspond directly to the VNC port number. An example would be VNC port 5922 with a forwarding port of 7022. It was worked great for us and I would like to see it as an integrated feature. On Apr 2, 2012 1:18 PM, Brian Hinz bph...@users.sourceforge.net mailto:bph...@users.sourceforge.net wrote: I've been working on adding support for the '-via' SSH tunneling feature that existed in the 1.1 client to the Java client (via JSch). I have a working version but before I commit anything I wanted to discuss the possibility of extending the functionality even further. What I'd like to propose is adding an SSH tab pane to the options dialog that would allow the user to setup forwarding of arbitrary ports. This could have a number of uses, such as making local LPD queues available, network audio, etc. My initial thought is that this tab pane would only be enabled prior to making the initial RFB connection, and I would try to keep it reasonably simple, having option fields for basic items such as private keys, known_hosts files, etc. in addition to the port forwarding fields. I realize that this is much more difficult to accomplish in the C client because of the external dependencies, so this would be a rather large disconnect between the two clients in terms of features... The second feature that I'd like to add is the one time password support that has been requested several times. I think that in general this is a feature that is more applicable to the Java client (particularly when deployed as an applet), so the discrepancy doesn't really bother me. I have not done any work to implement this yet, but seeing as Darrell mentioned that the TurboVNC viewer already supports it, I would probably pilfer the implementation from there. Comments, thoughts, objections to any of this? Thanks, -brian -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net mailto:Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] fontconfig linking issue
On 3/21/12 8:05 AM, Arthur Huillet wrote: For what it's worth, I think the issue is http://fedoraproject.org/wiki/UnderstandingDSOLinkChange Yes, someone already posted that link. I'm afraid I don't know how to do that. CMake is something I know enough to know that I don't want to know any more. :) It has its quirks, but so does every other system. The issue with autotools is that many projects depend on a specific version of it, and it's really difficult to install that specific version if your system doesn't have it, because autotools has a lot of external dependencies. CMake is genuinely cross-platform and very well self-contained, meaning that it's easy to install anywhere. However, it's not as hackable as autotools, meaning that if you discover an issue with it, it can sometimes be very difficult to work around. I think the link above explains that we're actually supposed to link against fontconfig explicitly, in all cases. As long as it doesn't break existing builds, I guess it's OK to include the patch? It *does* break existing builds, as I said. Specifically, Mac and Windows builds. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] My future involvement in the TigerVNC Project
On 3/13/12 5:45 AM, Adam Tkac wrote: May I ask you if you have any scripts which you used for building release/pre-release versions of TigerVNC? I would be glad if you share them. I cleaned them up and checked them into https://tigervnc.svn.sourceforge.net/svnroot/tigervnc/buildscripts/xc (NOTE: the buildscripts/ directory, in general, would be a good place to submit build scripts for other platforms as well, such as RHEL 6 or Ubuntu or other distros that require a specific build procedure to generate Xvnc against their built-in X server source.) It should be possible to exactly reproduce my builds using those scripts, provided you are building on the same build environment (see README.txt.) You can also use the included uploadtiger script to upload these to TigerVNC's SourceForge project web space, so you can provide a link to the pre-release builds (http://tigervnc.sourceforge.net/tiger.nightly) on the TigerVNC web page. And of course you know how to use the SourceForge FRS to do an official release, since you were doing that before I took over. Let me know if you encounter any issues with these, or have suggestions for their improvement. I use similar scripts to build TurboVNC and VirtualGL and libjpeg-turbo, so I want them to be as robust as possible. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] fontconfig linking issue
Just FYI-- I looked at this briefly, and from what I can tell, what you
really want to be doing is linking against Xft, not against fontconfig.
Also, I think you only want to link against it when building the Unix
viewer, not the other versions (pretty sure the patch below would cause
a Windows build, for instance, to fail.)
I think it may be an issue with the main CMakeLists.txt that occurs when
building against the in-tree version of FLTK. It doesn't appear to be
explicitly linking with Xft and other libraries in that case. Since I
can't repro the original issue, I can't really say what the right fix
is. I'm just throwing ideas out there.
On 2/28/12 10:34 AM, Paulo Edgar Castro wrote:
Hi there.
I was asked in the channel to raise this issue here...
I had been having some trouble trying to build the viewer. Kept on being
stopped by the following.
[100%] Building CXX object
vncviewer/CMakeFiles/vncviewer.dir/X11PixelBuffer.cxx.o
Linking CXX executable vncviewer
/usr/bin/ld: ../common/fltk/src/libfltk_static.a(fl_font.cxx.o):
undefined reference to symbol 'FcUtf8ToUcs4'
/usr/bin/ld: note: 'FcUtf8ToUcs4' is defined in DSO
/usr/lib64/libfontconfig.so.1 so try adding it to the linker command line
/usr/lib64/libfontconfig.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [vncviewer/vncviewer] Error 1
make[1]: *** [vncviewer/CMakeFiles/vncviewer.dir/all] Error 2
make: *** [all] Error 2
A couple of gents in the channel help me out and suggested I'd add
fontconfig to the line
-target_link_libraries(vncviewer rfb network rdr os Xregion
${FLTK_LIBRARIES} ${GETTEXT_LIBRARIES})
+target_link_libraries(vncviewer rfb network rdr os Xregion fontconfig
${FLTK_LIBRARIES} ${GETTEXT_LIBRARIES})
in vncviewer/CMakeLists.txt
which resulted in successful linking.
Should fontconfig be added there ?
Regards,
PECastro
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] 1.2?
Are we ready to release? -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] TigerVNC 1.2.0 has been released
https://sourceforge.net/projects/tigervnc/files/tigervnc/1.2.0/ Enjoy! -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] My future involvement in the TigerVNC Project
standalone cross-compatible product, and it can't really be made into one without basically re-architecting it. Doing that would require either an in-project or an out-of-project fork, and at this point, the prevailing desire within the VirtualGL community is just to go forward with TurboVNC instead. I wish you all the best of luck. DRC -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH 2/2] automatic lossless refresh: introduce lossy region tracking for smaller automatic updates.
On 3/2/12 3:32 AM, Arthur Huillet wrote:
--- a/common/rfb/tightEncode.h
+++ b/common/rfb/tightEncode.h
@@ -248,23 +248,28 @@ void TIGHT_ENCODE (const Rect r, rdr::OutStream *os,
bool forceSolid)
#if (BPP != 8)
if (jpegQuality != -1) {
encodeJpegRect(r, os);
+ lossy_tracker.add_changed(Region(r));
break;
}
#endif
ENCODE_FULLCOLOR_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
break;
case 1:
// Solid rectangle
ENCODE_SOLID_RECT(pixels, os);
+lossy_tracker.subtract(Region(r));
break;
case 2:
// Two-color rectangle
ENCODE_MONO_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
break;
#if (BPP != 8)
default:
// Up to 256 different colors
ENCODE_INDEXED_RECT(pixels, r, os);
+lossy_tracker.subtract(Region(r));
#endif
}
}
Why do you have to subtract the non-JPEG regions here? AFAICT, the
subrectangles within a given FBU are unique, but please correct me if
I'm wrong about that.
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Add an automatic lossless refresh mechanism.
Since I developed the original ALR mechanism for TurboVNC, I have a
couple of comments/critiques of this, based on the real-world usage of
the feature in TurboVNC. The first is that people use TurboVNC's ALR
feature in the medical viz industry, where mathematical losslessness is
important, so it's important that we have the ability to configure
either truly lossless (which I think should be the default) and
perceptually lossless transmission. As you know, TurboVNC configures
this via. -alrqual and -alrsamp command-line arguments (I think you were
the one who proposed that modification, actually.)
The second comment expands on Pierre's comment regarding tracking of
lossy regions. TurboVNC's version of the Tight encoder will track any
subrectangle that is encoded using JPEG and add it to a region called
lossyRegion. The ALR sends only the subrectangles in lossyRegion and
only if lossyRegion is not empty, and lossyRegion is immediately cleared
after the ALR is sent. Not all rectangles in the Tight protocol are
sent using JPEG encoding, even if JPEG is enabled. Rectangles with low
numbers of unique colors are sent using mathematically lossless indexed
color encoding. Thus, we don't want to re-send those during an ALR,
because -- best case -- we're duplicating effort and -- worse case -- if
the ALR is perceptually lossless, we're actually making the image
quality of those subrects worse.
On 2/27/12 5:31 AM, Arthur Huillet wrote:
It sends a full update of the screen, in high quality JPEG format, after a
programmable idle time.
This is disabled by default.
---
common/rfb/ServerCore.cxx |8
common/rfb/ServerCore.h |3 ++-
common/rfb/VNCSConnectionST.cxx | 29 -
common/rfb/VNCSConnectionST.h |3 +++
4 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/common/rfb/ServerCore.cxx b/common/rfb/ServerCore.cxx
index ae2fd24..583648e 100644
--- a/common/rfb/ServerCore.cxx
+++ b/common/rfb/ServerCore.cxx
@@ -93,4 +93,12 @@ rfb::BoolParameter rfb::Server::queryConnect
(QueryConnect,
Prompt the local user to accept or reject incoming connections.,
false);
+rfb::BoolParameter rfb::Server::automaticLosslessRefresh
+(AutomaticLosslessRefresh,
+ Automatically refresh the framebuffer with lossless compression.,
+ false);
+rfb::IntParameter rfb::Server::automaticLosslessRefreshDelay
+(AutomaticLosslessRefreshDelay,
+ Delay (in milliseconds) of inactivity after which to refresh framebuffer.,
+ 3000);
diff --git a/common/rfb/ServerCore.h b/common/rfb/ServerCore.h
index e12a8bc..745cdb5 100644
--- a/common/rfb/ServerCore.h
+++ b/common/rfb/ServerCore.h
@@ -38,6 +38,7 @@ namespace rfb {
static IntParameter maxIdleTime;
static IntParameter clientWaitTimeMillis;
static IntParameter compareFB;
+ static IntParameter automaticLosslessRefreshDelay;
static BoolParameter protocol3_3;
static BoolParameter alwaysShared;
static BoolParameter neverShared;
@@ -47,7 +48,7 @@ namespace rfb {
static BoolParameter acceptCutText;
static BoolParameter sendCutText;
static BoolParameter queryConnect;
-
+ static BoolParameter automaticLosslessRefresh;
};
};
diff --git a/common/rfb/VNCSConnectionST.cxx b/common/rfb/VNCSConnectionST.cxx
index deec186..ec2e35e 100644
--- a/common/rfb/VNCSConnectionST.cxx
+++ b/common/rfb/VNCSConnectionST.cxx
@@ -74,7 +74,7 @@ VNCSConnectionST::VNCSConnectionST(VNCServerST* server_,
network::Socket *s,
drawRenderedCursor(false), removeRenderedCursor(false),
continuousUpdates(false),
updateTimer(this), pointerEventTime(0),
-accessRights(AccessDefault), startTime(time(0))
+accessRights(AccessDefault), startTime(time(0)), alrTimer(this)
{
setStreams(sock-inStream(), sock-outStream());
peerEndpoint.buf = sock-getPeerEndpoint();
@@ -758,6 +758,10 @@ bool VNCSConnectionST::handleTimeout(Timer* t)
writeFramebufferUpdate();
else if (t == congestionTimer)
updateCongestion();
+ else if (t == alrTimer) {
+ fprintf(stderr, Doing ALR\n);
+ automaticLosslessRefresh();
+ }
} catch (rdr::Exception e) {
close(e.str());
}
@@ -971,6 +975,7 @@ void VNCSConnectionST::writeFramebufferUpdate()
// bit if things are congested.
if (isCongested()) {
updateTimer.start(50);
+alrTimer.stop();
return;
}
@@ -1070,6 +1075,7 @@ void VNCSConnectionST::writeFramebufferUpdate()
}
if (!ui.is_empty() || writer()-needFakeUpdate() || drawRenderedCursor) {
+alrTimer.stop();
// Compute the number of rectangles. Tight encoder makes the things more
// complicated as compared to the original VNC4.
writer()-setupCurrentEncoder();
@@ -1108,6 +1114,8 @@ void VNCSConnectionST::writeFramebufferUpdate()
requested.clear();
}
+ if (rfb::Server::automaticLosslessRefresh)
+
Re: [Tigervnc-devel] [PATCH] Add an automatic lossless refresh mechanism.
I still disagree with several things in general:
-- I didn't have a problem with the long variable names, but I would
prefer that the abbreviation ALR or alr be used instead of
automatic refresh. Automatic refresh is not a good name for the
feature.
-- For my purposes, the feature isn't useful unless it works the same
way as the equivalent feature in TurboVNC. That means that it needs
lossy region tracking and mathematically lossless needs to be the
default. Without that, I am not interested enough in it to justify
spending any time integrating and testing it. I do feel that we need to
come to an agreement on the interface for it, however, so later
enhancements won't require changing that. One reason why it's good to
have mathematically lossless be the default is that you don't have to
have the clunky use quality 10 as mathematical lossless rule. You
just set alrQuality to -1 by default, and the user overrides that to 0-9.
On 2/27/12 10:17 AM, Arthur Huillet wrote:
It sends a full update of the screen, in high quality JPEG format, after a
programmable idle time.
This is disabled by default. Quality can be configured and be truly lossless.
---
following remarks from Pierre and DRC, this patch is an improved version.
- fix codingstyle issues
- shorten automatic lossless refresh - automatic refresh
- refresh delay parameter is also used as a enabled boolean
- ALR quality selection, including truly lossless (no JPEG) mode
- manpage update
- timer is only started after an actual update was sent
It took me 20 minutes just trying to prove to myself that the truly
lossless mode worked (ie. that it wasn't merely using high quality JPEG).
Some people clearly have better eyes than I have - anyway, DRC, your users
should be happy now (but I didn't make true lossless the default).
The approach is rather naive and no tracking of the lossy regions is
attempted. This will be the subject of another patch. I deem the current
patch to be better than nothing and therefore request it be applied to
TigerVNC. (the second patch requires time - which I can find - and skill -
which I need to acquire - so it might not be done immediately).
common/rfb/ServerCore.cxx |8
common/rfb/ServerCore.h |3 ++-
common/rfb/VNCSConnectionST.cxx | 37 -
common/rfb/VNCSConnectionST.h |3 +++
unix/xserver/hw/vnc/Xvnc.man| 16
5 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/common/rfb/ServerCore.cxx b/common/rfb/ServerCore.cxx
index ae2fd24..ab332f5 100644
--- a/common/rfb/ServerCore.cxx
+++ b/common/rfb/ServerCore.cxx
@@ -93,4 +93,12 @@ rfb::BoolParameter rfb::Server::queryConnect
(QueryConnect,
Prompt the local user to accept or reject incoming connections.,
false);
+rfb::IntParameter rfb::Server::automaticRefreshDelay
+(AutomaticRefreshDelay,
+ Delay (in milliseconds) of inactivity after which to refresh framebuffer.
0 disables.,
+ 0);
+rfb::IntParameter rfb::Server::automaticRefreshQuality
+(AutomaticRefreshQuality,
+ JPEG Quality (0-9) for automatic refresh. Special value 10 uses
mathematically lossless compression.,
+ 9);
diff --git a/common/rfb/ServerCore.h b/common/rfb/ServerCore.h
index e12a8bc..2f93886 100644
--- a/common/rfb/ServerCore.h
+++ b/common/rfb/ServerCore.h
@@ -38,6 +38,8 @@ namespace rfb {
static IntParameter maxIdleTime;
static IntParameter clientWaitTimeMillis;
static IntParameter compareFB;
+static IntParameter automaticRefreshDelay;
+static IntParameter automaticRefreshQuality;
static BoolParameter protocol3_3;
static BoolParameter alwaysShared;
static BoolParameter neverShared;
@@ -47,7 +49,6 @@ namespace rfb {
static BoolParameter acceptCutText;
static BoolParameter sendCutText;
static BoolParameter queryConnect;
-
};
};
diff --git a/common/rfb/VNCSConnectionST.cxx b/common/rfb/VNCSConnectionST.cxx
index deec186..11a6ced 100644
--- a/common/rfb/VNCSConnectionST.cxx
+++ b/common/rfb/VNCSConnectionST.cxx
@@ -74,7 +74,7 @@ VNCSConnectionST::VNCSConnectionST(VNCServerST* server_,
network::Socket *s,
drawRenderedCursor(false), removeRenderedCursor(false),
continuousUpdates(false),
updateTimer(this), pointerEventTime(0),
-accessRights(AccessDefault), startTime(time(0))
+accessRights(AccessDefault), startTime(time(0)), refreshTimer(this)
{
setStreams(sock-inStream(), sock-outStream());
peerEndpoint.buf = sock-getPeerEndpoint();
@@ -758,6 +758,9 @@ bool VNCSConnectionST::handleTimeout(Timer* t)
writeFramebufferUpdate();
else if (t == congestionTimer)
updateCongestion();
+ else if (t == refreshTimer) {
+ automaticLosslessRefresh();
+}
} catch (rdr::Exception e) {
close(e.str());
}
@@ -971,6 +974,7 @@ void
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4857] trunk/java/com/tigervnc/vncviewer
I missed that part of the discussion on the tracker. What is the purpose of
having this in the viewer?
On Feb 16, 2012, at 6:44 AM, bph...@users.sourceforge.net wrote:
Revision: 4857
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4857view=rev
Author: bphinz
Date: 2012-02-16 12:44:51 + (Thu, 16 Feb 2012)
Log Message:
---
adds keepAlive feature requested in #3482254 to java viewer
Modified Paths:
--
trunk/java/com/tigervnc/vncviewer/CConn.java
trunk/java/com/tigervnc/vncviewer/VncViewer.java
Modified: trunk/java/com/tigervnc/vncviewer/CConn.java
===
--- trunk/java/com/tigervnc/vncviewer/CConn.java2012-02-16 12:31:38 UTC
(rev 4856)
+++ trunk/java/com/tigervnc/vncviewer/CConn.java2012-02-16 12:44:51 UTC
(rev 4857)
@@ -49,7 +49,8 @@
import java.net.InetSocketAddress;
import java.net.URL;
import java.net.SocketException;
-import java.util.*;
+import java.util.ArrayList;
+import java.util.Iterator;
import com.tigervnc.rdr.*;
import com.tigervnc.rfb.*;
@@ -227,6 +228,18 @@
setServerName(serverHost);
setStreams(sock.inStream(), sock.outStream());
initialiseProtocol();
+int delay = viewer.keepAliveTimeout.getValue();
+if (delay 0) {
+ ActionListener keepAliveListener = new ActionListener() {
+public void actionPerformed(ActionEvent evt) {
+ synchronized (writer()) {
+writer().writeFramebufferUpdateRequest(new Rect(0,0,0,0), true);
+ }
+}
+ };
+ keepAliveTimer = new Timer(1000*delay, keepAliveListener);
+ keepAliveTimer.start();
+}
}
public void refreshFramebuffer()
@@ -249,6 +262,8 @@
// deleteWindow() is called when the user closes the desktop or menu
windows.
void deleteWindow() {
+if (keepAliveTimer != null)
+ keepAliveTimer.stop();
if (viewport != null)
viewport.dispose();
viewport = null;
@@ -465,6 +480,8 @@
}
firstUpdate = false;
+ if (keepAliveTimer != null)
+keepAliveTimer.restart();
}
// A format change has been scheduled and we are now past the update
@@ -779,6 +796,8 @@
}
forceNonincremental = false;
+if (keepAliveTimer != null)
+ keepAliveTimer.restart();
}
@@ -1217,6 +1236,8 @@
synchronized public void writeClientCutText(String str, int len) {
if (state() != RFBSTATE_NORMAL) return;
writer().writeClientCutText(str,len);
+if (keepAliveTimer != null)
+ keepAliveTimer.restart();
}
synchronized public void writeKeyEvent(int keysym, boolean down) {
@@ -1388,6 +1409,8 @@
if ((m Event.META_MASK) != (pressedModifiers Event.META_MASK))
writeKeyEvent(Keysyms.Meta_L, (m Event.META_MASK) != 0);
pressedModifiers = m;
+if (keepAliveTimer != null)
+ keepAliveTimer.restart();
}
@@ -1421,6 +1444,7 @@
ImageIcon logo = new
ImageIcon(cl.getResource(com/tigervnc/vncviewer/tigervnc.png));
public static UserPasswdGetter upg;
public UserMsgBox msg;
+ Timer keepAliveTimer;
// shuttingDown is set by the GUI thread and only ever tested by the RFB
// thread after the window has been destroyed.
Modified: trunk/java/com/tigervnc/vncviewer/VncViewer.java
===
--- trunk/java/com/tigervnc/vncviewer/VncViewer.java2012-02-16 12:31:38
UTC (rev 4856)
+++ trunk/java/com/tigervnc/vncviewer/VncViewer.java2012-02-16 12:44:51
UTC (rev 4857)
@@ -331,6 +331,14 @@
Use specified compression level +
0 = Low, 6 = High,
1);
+ IntParameter keepAliveTimeout
+ = new IntParameter(KeepAliveTimeout,
+ Send dummy framebuffer update requests if no +
+ network activity has occurred for more than +
+ the specified number of seconds. This is to +
+ prevent VPNs or other applications from +
+ disconnecting due to inactivity. A value of +
+ 0 disables this feature., 0);
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.
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Tigervnc-commits mailing list
tigervnc-comm...@lists.sourceforge.net
Re: [Tigervnc-devel] r4841
On 2/10/12 11:15 AM, Pierre Ossman wrote:
You mean this code?
if (ig-willTransform()) {
ig-translatePixels(pixels, solidColor, 1);
pixels = (PIXEL_T *)solidColor;
}
I don't follow. As you can see, it changes the value of the pixels
pointer so that it points at the local solidColor variable and no
longer at the framebuffer, so the framebuffer is not modified. I can't
see any other place in the code where the framebuffer was being modified.
But ig-willTransform() can return false, which is even the common case.
I have confirmed that 4841 is not correct. The reason why is that it
assumes that JPEG will always be encoded from the raw pixel buffer, but
that is not always the case. JPEG is only encoded from the raw buffer
whenever no pixel translation is taking place. Otherwise, it will
encode from the translated buffer. The reason for this is so we don't
end up doing pixel translation twice. If, for instance, the server is
16-bpp but the client is 32-bpp, then JPEG can be encoded directly from
the translated buffer instead of having to re-translate the pixels from
16-bit to 24-bit within the JPEG compressor.
This is also why the if(grayScaleJPEG) test has to be in both logical
branches. The way 4841 was written, grayscale mode would not work
properly if JPEG was being compressed from a translated pixel buffer.
Further, this is also why the encodeJpegRect*() routines use clientpf
instead of serverpf (4841 broke this as well.) What's particularly
annoying is that a quick 'svn log' would reveal that the code structure
used by r4841 was already determined to be faulty and fixed by r4642.
4851 and 4852 fixes the regression in both trunk and 1.2, as well as
fixing the initial issue that prompted 4841. I have re-tested at the
low level to ensure that performance has not been affected by this and
that the datastream is byte-accurate relative to r4840.
At this point, I'm not going to lecture anymore regarding checking in
potentially destabilizing code post-beta, but I will beg and plead again
that you (a) treat the Tight encoder as a separate piece of
infrastructure and assume that it will require manual low-level
regression and performance testing every time it is modified and (b)
file bug reports on any issues related to it. When I've made this
request in the past, I've been accused of trying to stifle open
development in this project, but I assure you that that's not the case.
I assure you that other open source projects like Mozilla make the same
requirements of their image codec infrastructure (much stricter ones,
typically.) Any complicated image encoder is a delicate beast requiring
extensive testing when it is modified. The difference between our
project and others is that others typically automate that process, and
that's something TigerVNC really should do as well. I'm not
volunteering to make that happen, but until/unless it does, we can't
just modify the encoder and expect that it is regression-proof because
the high-level tests don't reveal anything. Every potentially
regressive modification to that code must be tested manually at the low
level.
Regarding formatting, my coding style favors preservation of vertical
space, because studies (as well as my own experience) have shown that
code is more readable when you can see more of its logical flow at once.
However, I compromised with you on that in 4851 and 4852, preserving
some of your formatting changes from 4841 that made sense. I also
improved the comments to better describe what the code is doing
vis-a-vis pixel translation.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4842] trunk/java
On 2/3/12 12:12 AM, Brian Hinz wrote: Sorry, my bad, I thought you had actually branched 1.2 already. I don't think this is release ready code, would it make more sense to branch at 4840 or 4841, or for me to back out 4842 temporarily and re-apply after you branch? The 1.2 branch has now been created. I back-ported 4843 into it as you suggested, but please back-port any other stable patches that you think need to be in 1.2. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4841] trunk/common/rfb
I've stared at the code yet again and can't see where the corruption was occurring prior to 4841. I understand and agree with you setting the various method arguments to const. That's not the issue. The issue is that I don't understand why some of the code in tightEncode.h was moved around-- particularly why encodeJpegRect16() and encodeJpegRect32() were replaced with encodeJpegRect(). Yes, I see that you're now re-calling ig-getRawPixelsR() in the body of encodeJpeg(), but why? On 2/3/12 9:00 AM, Pierre Ossman wrote: On Tue, 31 Jan 2012 05:03:06 -0600 DRC dcomman...@users.sourceforge.net wrote: I have not seen this, either in high-level or low-level tests. Please explain how to reproduce it. The easiest way to provoke it is with a composited desktop and a solid blue background. I've been using the Gnome 3 fallback on Fedora 16. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4841] trunk/common/rfb
On 2/9/12 6:34 AM, Pierre Ossman wrote:
On Sun, 05 Feb 2012 15:32:52 -0600
DRC dcomman...@users.sourceforge.net wrote:
Perhaps I'm still missing something, because after examining the patch
again, I don't see where the original buffer corruption was occurring or
how your patch fixes it. Part of the difficulty in analyzing this patch
is that you seem to have taken the opportunity to move a lot of things
around to conform to your own personal preferences. I would ask you to
please reformulate the patch with as few changes as possible and to
clarify where the buffer corruption was occurring.
The specific bug I was reproducing was caused by the force solid code
path, which kept pixels pointing at the frame buffer. To be able to
audit the rest of the code for similar misuse, I needed to clear it up
so it was easier to follow. Just the addition of const pointers required
substantial changes. As part of this the JPEG code was changed to make
it painfully obvious it behaves very differently from the other parts
of the tight encoder.
You mean this code?
if (ig-willTransform()) {
ig-translatePixels(pixels, solidColor, 1);
pixels = (PIXEL_T *)solidColor;
}
I don't follow. As you can see, it changes the value of the pixels
pointer so that it points at the local solidColor variable and no
longer at the framebuffer, so the framebuffer is not modified. I can't
see any other place in the code where the framebuffer was being modified.
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4842] trunk/java
I hadn't actually branched 1.2 yet, so trunk is still supposed to be stable. I was waiting for a more reasonable explanation of 4841 from Pierre before branching, as that patch appears destabilizing as well. On 2/2/12 11:38 PM, bph...@users.sourceforge.net wrote: Revision: 4842 http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4842view=rev Author: bphinz Date: 2012-02-03 05:38:23 + (Fri, 03 Feb 2012) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4842] trunk/java
I can branch at 4840 or 4841 and leave your patch in, but we need to figure out which is the branch point fairly quickly before someone tries to create a bug fix for the stable code. I'll also need to bump the revision in trunk to avoid confusion. On 2/3/12 12:12 AM, Brian Hinz wrote: Sorry, my bad, I thought you had actually branched 1.2 already. I don't think this is release ready code, would it make more sense to branch at 4840 or 4841, or for me to back out 4842 temporarily and re-apply after you branch? Thanks, -brian On Fri, Feb 3, 2012 at 12:51 AM, DRC dcomman...@users.sourceforge.net mailto:dcomman...@users.sourceforge.net wrote: I hadn't actually branched 1.2 yet, so trunk is still supposed to be stable. I was waiting for a more reasonable explanation of 4841 from Pierre before branching, as that patch appears destabilizing as well. On 2/2/12 11:38 PM, bph...@users.sourceforge.net mailto:bph...@users.sourceforge.net wrote: Revision: 4842 http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4842view=rev http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4842view=rev Author: bphinz Date: 2012-02-03 05 tel:2012-02-03%2005:38:23 + (Fri, 03 Feb 2012) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net mailto:Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4841] trunk/common/rfb
On 1/31/12 2:57 AM, Pierre Ossman wrote: On Mon, 30 Jan 2012 15:55:11 -0600 DRC dcomman...@users.sourceforge.net wrote: How does it not work so well? You can't just commit potentially disruptive patches after the code has been stabilized without first opening them up for discussion. I expect a more detailed answer than your commit log below. The tight encoder _writes_ to the pixel buffer given to it, corrupting the screen contents. I have not seen this, either in high-level or low-level tests. Please explain how to reproduce it. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4841] trunk/common/rfb
How does it not work so well? You can't just commit potentially
disruptive patches after the code has been stabilized without first
opening them up for discussion.
I expect a more detailed answer than your commit log below.
On 1/30/12 7:58 AM, ossm...@users.sourceforge.net wrote:
Revision: 4841
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4841view=rev
Author: ossman_
Date: 2012-01-30 13:58:44 + (Mon, 30 Jan 2012)
Log Message:
---
The Tight encoder uses the pixel buffer as a scratch pad, which doesn't
work so well with the new optimisation to feed it the raw frame buffer.
Reorganise and clean up the code to handle this, and make the raw frame
buffer pointer const so that we might avoid such bugs in the future.
Modified Paths:
--
trunk/common/rfb/TightEncoder.cxx
trunk/common/rfb/TightEncoder.h
trunk/common/rfb/TransImageGetter.cxx
trunk/common/rfb/TransImageGetter.h
trunk/common/rfb/tightEncode.h
Modified: trunk/common/rfb/TightEncoder.cxx
===
--- trunk/common/rfb/TightEncoder.cxx 2012-01-30 13:53:11 UTC (rev 4840)
+++ trunk/common/rfb/TightEncoder.cxx 2012-01-30 13:58:44 UTC (rev 4841)
@@ -418,3 +418,19 @@
os-writeBytes(mos.data(), mos.length());
writer-endRect();
}
+
+void TightEncoder::encodeJpegRect(const Rect r, rdr::OutStream *os)
+{
+ const rdr::U8 *buf;
+ int stride;
+
+ buf = ig-getRawPixelsR(r, stride);
+
+ jc.clear();
+ jc.compress(buf, stride * serverpf.bpp / 8, r, serverpf,
+ jpegQuality, jpegSubsampling);
+
+ os-writeU8(0x09 4);
+ os-writeCompactLength(jc.length());
+ os-writeBytes(jc.data(), jc.length());
+}
Modified: trunk/common/rfb/TightEncoder.h
===
--- trunk/common/rfb/TightEncoder.h 2012-01-30 13:53:11 UTC (rev 4840)
+++ trunk/common/rfb/TightEncoder.h 2012-01-30 13:58:44 UTC (rev 4841)
@@ -100,9 +100,9 @@
int paletteInsert(rdr::U32 rgb, int numPixels, int bpp);
void paletteReset(void);
-void fastFillPalette8(rdr::U8 *data, int stride, const Rect r);
-void fastFillPalette16(rdr::U16 *data, int stride, const Rect r);
-void fastFillPalette32(rdr::U32 *data, int stride, const Rect r);
+void fastFillPalette8(const rdr::U8 *buffer, int stride, const Rect r);
+void fastFillPalette16(const rdr::U8 *buffer, int stride, const Rect r);
+void fastFillPalette32(const rdr::U8 *buffer, int stride, const Rect r);
void fillPalette8(rdr::U8 *data, int count);
void fillPalette16(rdr::U16 *data, int count);
@@ -135,10 +135,7 @@
void encodeIndexedRect16(rdr::U16 *buf, const Rect r, rdr::OutStream
*os);
void encodeIndexedRect32(rdr::U32 *buf, const Rect r, rdr::OutStream
*os);
-void encodeJpegRect16(rdr::U16 *buf, int stride, const Rect r,
- rdr::OutStream *os);
-void encodeJpegRect32(rdr::U32 *buf, int stride, const Rect r,
- rdr::OutStream *os);
+void encodeJpegRect(const Rect r, rdr::OutStream *os);
SMsgWriter* writer;
rdr::MemOutStream mos;
Modified: trunk/common/rfb/TransImageGetter.cxx
===
--- trunk/common/rfb/TransImageGetter.cxx 2012-01-30 13:53:11 UTC (rev
4840)
+++ trunk/common/rfb/TransImageGetter.cxx 2012-01-30 13:58:44 UTC (rev
4841)
@@ -56,12 +56,12 @@
PixelTransformer::setColourMapEntries(firstCol, nCols);
}
-rdr::U8 *TransImageGetter::getRawPixelsRW(const Rect r, int *stride)
+const rdr::U8 *TransImageGetter::getRawPixelsR(const Rect r, int *stride)
{
if (!offset.equals(Point(0, 0)))
-return pb-getPixelsRW(r.translate(offset.negate()), stride);
+return pb-getPixelsR(r.translate(offset.negate()), stride);
else
-return pb-getPixelsRW(r, stride);
+return pb-getPixelsR(r, stride);
}
void TransImageGetter::getImage(void* outPtr, const Rect r, int outStride)
Modified: trunk/common/rfb/TransImageGetter.h
===
--- trunk/common/rfb/TransImageGetter.h 2012-01-30 13:53:11 UTC (rev
4840)
+++ trunk/common/rfb/TransImageGetter.h 2012-01-30 13:58:44 UTC (rev
4841)
@@ -72,11 +72,11 @@
// padding will be outStride-r.width() pixels).
void getImage(void* outPtr, const Rect r, int outStride=0);
-// getRawPixelsRW() gets the given rectangle of data directly from the
+// getRawPixelsR() gets the given rectangle of data directly from the
// underlying PixelBuffer, bypassing the translation logic. Only use
// this when doing something that's independent of the client's pixel
// format.
-rdr::U8 *getRawPixelsRW(const Rect r, int *stride);
+const rdr::U8 *getRawPixelsR(const Rect r, int *stride);
//
Re: [Tigervnc-devel] Cendio preparing for new release
On Dec 28, 2011, at 9:25 AM, Peter Åstrand astr...@cendio.se wrote: On 12/22/11 2:41 AM, Peter Åstrand wrote: I'll let Pierre give you the details of the -DeferUpdate values, but if it turns out that it's not possible to find a default that fits everyone, then I'm suggesting that we create a special script turbovncserver, vglvncserver or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick dirty benchmarks. We need something more quantifiable. I think we have provided quantifiable data. If you did, I never saw it. I agree that additional tests would be useful though, but there are also other things that needs attention. I think the core of the problem is there will always be some kind of tradeoff/compromise, and if I understand the VirtualGL/TurboVNC perspective correctly, there's no interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. Not difficult at all. We have a solution that fits both use cases by default: it's the same solution we used with 1.1.0 and are now using with 1.2 beta1, which is setting DeferUpdate to 1 ms. You and Pierre have not provided any test cases which demonstrate that 10 ms is beneficial, and Pierre admitted that the choice of that value was more of a gut instinct, which is why we changed it back until further information can be gathered. Pierre and I have reached at least a temporary agreement regarding this, so I'm not sure what you hope to gain by continuing to argue the point. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] 2D vs 3D performance
On Dec 28, 2011, at 10:22 AM, Peter Åstrand astr...@cendio.se wrote: On Wed, 28 Dec 2011, DRC wrote: I'm pretty sure the message from Pierre was that it's not important enough to block a new release; not that we have a solution that fits both use cases optimally. We might solve the -DeferUpdate problem, but as long as the VirtualGL/TurboVNC standpoint is no compromise at all, any CPU increase is a no-no etc, there will be tons of issues on which we cannot find solutions that are optimal for both cases. Without room for compromises and tradeoffs, it's an impossible goal. Compromise doesn't mean you always get your way and DRC always gets shouted down. We compromised on the compression level. I conceded re-enabling the CUT on CL 2 and above and making CL 2 the default as long as there was an easy way to get back the Turbo behavior without restarting the server. However, the data supporting your case was, in my opinion, still weak there as well. It was based on quick dirty benchmarks of two apps. That doesn't quite measure up to my lengthy reports that are the culmination of hundreds of hours of research. I refuse to be vilified for wanting to maintain the same levels of performance for 3D and video apps as TurboVNC. These apps are more performance-critical than Firefox and OpenOffice. But I'm also quite willing to try to find a solution they satisfies both types of apps. I have done this before, as one of the afore-mentioned lengthy reports describes. But you seem so insistent that there is no solution and you'd rather edge me out of the project than try to find one. Having a special script for the ultimate-performance-on-LAN-case would be an easy solution. Let's be clear. The difference between DeferUpdate=1 and DeferUpdate=10 is 30%, enough to effectively erase all of the hard-fought performance gains since 1.1. The performance drop affects not just LAN performance but WAN performance. My basic points all along have been that: (a) If you and Cendio have apps that you care more about than the ones I have extensively tested, then you need to develop your own low-level datasets and quantify the performance under those apps in the same way that I have for the apps I care about. Simply arguing vague points like we can't favor LAN performance over WAN performance or we can't favor 3D performance over 2D performance is useless unless you have established quantitatively that we have to favor one over the other, but you haven't. There are knobs that can be adjusted at the low level that make quite a difference with specific apps, and sometimes those knobs can be adjusted without affecting other apps too severely. (b) Never did I say that I am unwilling to compromise, but what I am unwilling to do is completely write VirtualGL users out of the picture. My only demand is that there is a Turbo-equivalent mode that is client-side configurable. If we start getting into such esoteric stuff as having separate launcher scripts, then why wouldn't I just create a completely different build procedure that gives me all the defaults I want? Or better yet, why wouldn't I just fork the project so I wouldn't have to deal with your grief anymore?-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] 1.1.90 (1.2 beta1) has been released
https://sourceforge.net/projects/tigervnc/files/tigervnc/1.1.90%20%281.2beta1%29/ Enjoy! -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/21/11 4:30 AM, Pierre Ossman wrote: There was a request to let the community know a bit more about what Cendio is up to with regard to releases. So I'd like to take this opportunity to mention that we are releasing a beta for our next release, meaning we are going into pure bug squashing mode now. If you'd like to test our build, then send a mail to support at cendio.com and we'll give you a download link. We are currently based on TigerVNC revision 4816, but we might make a new code drop if we find any major bugs. Cool. This is very good info. AFAIC, we could enter beta with the project as well, and probably should so we can leverage your bug squashing. It would be nice to get out some official project builds that contain the performance improvements. I would still like to see a quantifiable test case that demonstrates the efficacy of setting the deferred update timer to 10 ms. Barring that, if you're insistent that 10 is what you want as a default, I would like to modify the build system such that that value can be tweaked using a #define or something like that, so my builds can use 1 ms as the default. It's pretty easy to tell people if you want TurboVNC-like performance, set the compress level to 1, but telling them that they also have to remember to add -DeferUpdate=1 every time they launch vncserver makes things difficult. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Fix latency issue
On 12/9/11 3:35 AM, Pierre Ossman wrote: If I instead run with the regular 100 Mbps transfer rate but still artificially add latency via qdisc, then I can see a clear benefit, both qualitatively and quantitatively-- as long as I jack up the TCP max buffer sizes to 8 MB in /etc/sysctl.conf: The default of 4 MB was insufficient for you? I never hit that size during my tests. The default wmem_max on Red Hat Enterprise 5 is much lower than 4 MB-- more like 256k, I think. TigerVNC is using something like 2 MB whenever it's delivering its best performance in the 200 ms configuration. I'm not sure how realistic that configuration is, but it's not the first time I've used it for benchmarking. I have yet to find a reliable way to limit the bandwidth. At least on my system, trying to use qdisc for that as well produces very unpredictable results. It has worked fine here for us. I can dig up the script we use if you'd like. Yes, I'd like to see that. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Fix latency issue
More news on this. At least part of the issue seems to have been hardware-related. For some reason (possibly my network switch, because I seem to get the same behavior from multiple machines), whenever I manually set either my server or client NIC to 10 Mbps, it produces an odd performance curve that drops off sharply past about an 8k transfer size, to the point that the typical transfer sizes being sent by TigerVNC perform at more like 2 Mbps, even with no latency added. Thus, the performance was being limited by the bandwidth, which is why I didn't see any benefit to the advanced flow control features. If I instead run with the regular 100 Mbps transfer rate but still artificially add latency via qdisc, then I can see a clear benefit, both qualitatively and quantitatively-- as long as I jack up the TCP max buffer sizes to 8 MB in /etc/sysctl.conf: net.core.rmem_max = 8388608 net.core.wmem_max = 8388608 net.ipv4.tcp_rmem = 4096 87380 8388608 net.ipv4.tcp_wmem = 4096 65536 8388608 I'm not sure how realistic that configuration is, but it's not the first time I've used it for benchmarking. I have yet to find a reliable way to limit the bandwidth. At least on my system, trying to use qdisc for that as well produces very unpredictable results. I ported over the fake mouse event generator that I use in TurboVNC to test interactive performance (patch attached, if anyone is interested. The only reason I didn't check it in is that I don't know if it is of any use for testing applications other than GLXspheres. For a more typical 3D app, for instance, it would probably be necessary to simulate more of a cross-screen back-and-forth drag instead of just a mouse wiggle.) To test performance, I run 'vglrun /opt/VirtualGL/bin/glxspheres64 -fs -i' on the server and then start the client with 'TVNC_FAKEMOUSE=1 vncviewer'. Once connected, pressing both left and right mouse buttons at the same time activates/deactivates the fake mouse event generator, which will stream mouse events every 10 ms to the server, causing the spheres to animate. /opt/VirtualGL/bin/tcbench is then used to record the actual throughput on the client. I observe that, with the 11/08 build and 200 ms of simulated latency, the frame rate was latency-limited to 5 Hz. In the 11/23 build, after some initial variability as Linux autotunes the TCP parameters, the frame rate settles into about the same level as it is with no latency. I tested with compress level = 1 and quality level = 8. I do still observe a 1/3 drop in performance relative to using a deferred update timer of 1 ms, however. This is true with both the 200 ms and 0 ms latency cases. I will restate my desire to change this back to a default of 1 ms, unless there is compelling quantitative evidence to indicate that a 10 ms DUT is beneficial. On 12/7/11 2:45 AM, Pierre Ossman wrote: Any luck getting this working? On Thu, 1 Dec 2011 11:31:25 +0100 Pierre Ossman oss...@cendio.se wrote: On Wed, 30 Nov 2011 15:47:14 -0600 DRC dcomman...@users.sourceforge.net wrote: Yes, I'm getting the enabling continuous updates message. How I'm testing is to look at responsiveness when running 'vglrun glxspheres -i -fs' with quality=1 and compress level=1. I move the mouse across the screen and gauge (with a stopwatch) how long it takes for the server to catch up. It's consistently about 1.5 seconds both before and after the high-latency modifications. TurboVNC performs similarly with similar quality/compress level (Low-Quality JPEG preset.) Not sure I'm understanding your test case. The mouse is normally rendered locally and not latency sensitive. Or are you disabling that for the test? GLXspheres at this quality level is going to cause Tiger/TurboVNC to generate about 0.5 Mbits/frame of data at 1240x900, so if the frame rate is not latency-limited, TigerVNC should be capable of at least 5-6 Hz given the effective bandwidth of the 10 Mbit connection. However, it seems to be still generating about 3 Hz, the same as it did before the modifications. Odd. There is a corner case where single updates exceed the congestion window, but that shouldn't happen here. For 10 Mbit at 100 ms RTT, it should have a window of at least 1 Mbit, meaning it should fit two or three of those updates in there per round trip. Can you try with the congestion debugging turned on and see what latency and congestion window it gets? I also do not notice any difference when typing into a console window, moving windows around, etc. Further, it appears that double buffering is not working quite right, but that's the case in the pre-modified build as well. In what way? At such low frame rates, perhaps you're hitting the timer which prematurely updates the screen so it won't appear frozen. Rgds Index: vncviewer/Viewport.cxx === --- vncviewer/Viewport.cxx (revision 4819) +++ vncviewer/Viewport.cxx
Re: [Tigervnc-devel] [PATCH] Fix latency issue
A follow-up question: I'm probably fundamentally misunderstanding something still, but I'm wondering why it is necessary to ping-pong off of the client to obtain the RTT, when TCP_INFO can give you that information (through TCP_INFO) without extending the RFB protocol. On 12/7/11 2:45 AM, Pierre Ossman wrote: Any luck getting this working? On Thu, 1 Dec 2011 11:31:25 +0100 Pierre Ossman oss...@cendio.se wrote: On Wed, 30 Nov 2011 15:47:14 -0600 DRC dcomman...@users.sourceforge.net wrote: Yes, I'm getting the enabling continuous updates message. How I'm testing is to look at responsiveness when running 'vglrun glxspheres -i -fs' with quality=1 and compress level=1. I move the mouse across the screen and gauge (with a stopwatch) how long it takes for the server to catch up. It's consistently about 1.5 seconds both before and after the high-latency modifications. TurboVNC performs similarly with similar quality/compress level (Low-Quality JPEG preset.) Not sure I'm understanding your test case. The mouse is normally rendered locally and not latency sensitive. Or are you disabling that for the test? GLXspheres at this quality level is going to cause Tiger/TurboVNC to generate about 0.5 Mbits/frame of data at 1240x900, so if the frame rate is not latency-limited, TigerVNC should be capable of at least 5-6 Hz given the effective bandwidth of the 10 Mbit connection. However, it seems to be still generating about 3 Hz, the same as it did before the modifications. Odd. There is a corner case where single updates exceed the congestion window, but that shouldn't happen here. For 10 Mbit at 100 ms RTT, it should have a window of at least 1 Mbit, meaning it should fit two or three of those updates in there per round trip. Can you try with the congestion debugging turned on and see what latency and congestion window it gets? I also do not notice any difference when typing into a console window, moving windows around, etc. Further, it appears that double buffering is not working quite right, but that's the case in the pre-modified build as well. In what way? At such low frame rates, perhaps you're hitting the timer which prematurely updates the screen so it won't appear frozen. Rgds -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] The deferred update timer
On 12/7/11 2:44 AM, Pierre Ossman wrote:
Annoying. I did some work at making the thing more asynchronous, but
more might be needed. If the problem is getting the data on the wire
rather than the actual encoding, then a quick fix is increasing the
outgoing buffer size. As long as your entire update fits in there, then
X won't be throttled (and the update timer should also be more precise).
Not sure if I follow. It's not the send delay that's the problem-- it's
the time that the CPU takes to encode the framebuffer.
Just wanted to double check that you've looked at actual CPU time, and
not the wall time it spends in writeFramebufferUpdate(). The latter
includes both CPU time and the time needed to drain the socket buffer
(if it fills).
This is an Amdahl's Law thing. The frame rate is capped to 1 /
({deferred update time} + {FBU processing time}). Whether or not the
FBU processing time is all CPU or some CPU and some I/O is irrelevant.
As long as the server can't receive new X updates during that time, then
the effect is the same.
Now, with the latest TigerVNC code, my understanding of it is that
FBUR's no longer result in an immediate FBU unless there is no deferred
update currently in progress. Thus, almost all updates will be deferred
updates now. That means that we're always going to incur the overhead
of the deferred update timer on every frame.
Indeed. The purpose of the deferred updates is to aggregate X11 stuff,
and so should be fairly independent of what the VNC clients are up to.
Note that FBUR:s still have some influence here as it will continue to
aggregate stuff (and not reset the timer) if there is no client ready.
As to a solution, the only proper one is to reduce the time spent
encoding stuff. We can't really do it in the background as we can't
No, because, per above, if we speed up processing, then the DUT delay
will have more of a relative effect, not less. If it takes 10 ms on
average to process every update, then the difference between a 1 ms and
a 10 ms DUT is a 45% throughput loss. If it takes 100 ms on average to
process every update, then the difference between a 1 ms and a 10 ms DUT
is only an 8% throughput loss.
allow the framebuffer to be modified whilst we're encoding. Double
buffering is one way to go, but I wouldn't be surprised if the copying
between the buffers would eat up any performance gain.
It wouldn't eat up any performance gain. memcpy()ing large blocks is
typically very quick, and actually, the CUT is already double buffering.
However, double buffering does eat up a lot of memory. I looked into
double buffering with TurboVNC, in an attempt to figure out how to
create a separate compress/send thread for each client and do flow
control that way (the way VirtualGL does it.) Ultimately, I figured out
that it was possible, but it would require maintaining an intermediary
buffer for each client, and you can imagine that with the 4-megapixel
sessions that TurboVNC users commonly use, if they try to collaborate
with 5 people, suddenly they have a 100 MB VNC process on their hands.
That said, perhaps we can consider treating this as a corner case and
dial back the aggregation when we are hitting the CPU wall.
Well, ultimately the purpose of
aggregation/coalescence/whatever-you-want-to-call-it is increased
performance, so I'm assuming there is data to show that 10 ms performs
better than 1 ms under certain conditions? I have never seen it to have
any effect other than a negative one, either on a WAN or a LAN. We
really need to figure out a way to address these issues quantitatively,
because I feel like I have a lot of data to show what does and doesn't
work for 3D and video apps, but there is not the same data to show what
does and doesn't work for Firefox or OpenOffice or whatever, nor a
reproducible way to measure the effect of certain design decisions on
such apps.
I will also say that LAN usage is not a corner case, and if we treat it
as such, it will become a self-fulfilling prophesy, because no one will
want to use TigerVNC on a LAN if it's slow.
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] The deferred update timer
When the deferred update timer behavior was recently overhauled such that it pushes out updates whenever the timer is triggered rather than waiting for an update request from the client, the default DUT value was also changed to 10 ms (from 1 ms.) Unfortunately, setting the DUT to 10 ms results in a dramatic decrease in peak performance on high-speed networks. The reason is that, when the timer is set, all X updates that arrive between that time and the time it is triggered are coalesced. As soon as the timer is triggered, a framebuffer update containing all of the coalesced X updates is sent immediately, then the server is tied up sending the update and cannot process any new X updates until the update is sent. Once the update is sent, then the first new X update starts the deferred update timer again. Effectively, what this means is that the frame rate is capped to 1 / (deferred update time + encoding time), and since the encoding time is typically about 20 ms for a 1280x1024 screen, setting the DUT to 10 ms caps the frame rate at about 30 Hz for such a screen, whereas previously it was near 50 Hz when the DUT was 1 ms. I'm not sure how best to address this, but it does represent a performance regression, since LAN performance has now decreased by 40% with default settings. DRC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Fix latency issue
On 11/29/11 4:14 AM, Pierre Ossman wrote: It would really be nice to quantify it somehow, because it doesn't seem to be any better in terms of responsiveness, either. I'm testing up in the range of 100-200 ms ping time, or rather, 50-100 ms added on both ends. That's odd. Maybe it's not being properly enabled. Are you getting enabling continuous updates in the output from the client? The only numbers you can easily get is to turn on the debugging info for the congestion control. There's a define at the top of VNCSConnection.cxx. It will also provide the kernel's view of things for reference (only relevant if you're not using any proxying). Yes, I'm getting the enabling continuous updates message. How I'm testing is to look at responsiveness when running 'vglrun glxspheres -i -fs' with quality=1 and compress level=1. I move the mouse across the screen and gauge (with a stopwatch) how long it takes for the server to catch up. It's consistently about 1.5 seconds both before and after the high-latency modifications. TurboVNC performs similarly with similar quality/compress level (Low-Quality JPEG preset.) GLXspheres at this quality level is going to cause Tiger/TurboVNC to generate about 0.5 Mbits/frame of data at 1240x900, so if the frame rate is not latency-limited, TigerVNC should be capable of at least 5-6 Hz given the effective bandwidth of the 10 Mbit connection. However, it seems to be still generating about 3 Hz, the same as it did before the modifications. I also do not notice any difference when typing into a console window, moving windows around, etc. Further, it appears that double buffering is not working quite right, but that's the case in the pre-modified build as well. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Can we *please* revisit the reply policy on this list?
When we created this project a couple of years ago, it was decided (I was outvoted) that mailing list replies would go to the user rather than the list, but we are losing a lot of information this way. People will typically hit Reply rather than Reply All, and their response will go only to the poster, even though the information is relevant to the entire list. Thus, we are in some cases losing records of solutions to problems or vital diagnostic information that could be useful to someone searching for a solution to the same issue. Can we please re-visit this? DRC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Fix latency issue
On 11/29/11 3:34 AM, Pierre Ossman wrote: In the next-gen version of TurboVNC, manually enabling the Continuous Updates extension (which causes the TurboVNC server to send updates immediately to the client) produces significantly better throughput on this type of connection, but none of the TigerVNC enhancements seem to have improved its throughput. We've been focusing on responsiveness, but that should be correlated with throughput. Example tests have been typing, dragging things around and playing movies. Note that maximum throughput has explicitly not been the goal. Doing so would have ruined latency as that fills up buffers. The goal of the algorithm is to maximize throughput without sacrificing latency. In practice it can of course never be perfect, but the numbers I've seen during my tests shows that it tends to be pretty damn close. Further improvements can probably be made, but we're at a point where we deem it good enough for now and are looking to put the stuff in the hands of users first. It would really be nice to quantify it somehow, because it doesn't seem to be any better in terms of responsiveness, either. I'm testing up in the range of 100-200 ms ping time, or rather, 50-100 ms added on both ends. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Security for multiple client types
On 11/22/11 3:07 PM, Martin Koegler wrote: On Tue, Nov 22, 2011 at 05:39:54PM +, Dan Garton wrote: I'm still in the process of developing an integrated remote desktop system for a specialist user base, and am using TigerVNC to great effect so far. I would like to enable client connections from standard Win/Mac/Lin desktops (using the Tiger VncViewer) and ALSO client connections from mobile devices such as iOS / Android etc. The problem being, there are no free/open mobile (iOS/Android) VNC clients which implement encryption - yet. If I run the Xvnc server with SecurityType=None (which I would need to do to allow these mobile clients to connect), HOW can I make it more secure? Obviously, the password is still sent encrypted (I believe) but the RFB communication is open and in the clear (albeit using TightVNC encoding). To expand upon what Martin said, SecurityType=VncAuth (VNC Password Authentication) is the classic way of authenticating with VNC servers, and every mobile VNC client I've seen supports that. However, it's not really secure. The password is sent using DES3, so it can't be casually sniffed, but the session is not encrypted at all once the password is transmitted, so any other passwords you type while connected will be completely readable. Probably not a big deal if you're running within a secure corporate network without root access, but outside of a firewall, it's an issue. The issue with VNC on iOS is that Apple won't allow any GPL-licensed apps in the App Store, so that effectively eliminates one's ability to leverage code from TigerVNC (or most other VNC code bases) in an iPhone app. It probably prevents one from using LGPL-licensed libraries such as GnuTLS as well (TigerVNC uses GnuTLS to implement its built-in encryption.) The terms of the LGPL are such that you would have to provide source for the library as well as object files for the rest of the VNC viewer, and my understanding is that any such viral provisions are incompatible with the App Store. Android would be an easier target. I don't think it already has GnuTLS, so it would probably be necessary to build those libraries and statically link against them, but the Android Market does allow GPL'ed software, so it would be theoretically possible to extend one of the existing Android VNC clients. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance
Not sure if I understand why it couldn't be overridden by passing compareFB=1 on the command prompt to always enable it. On 11/17/11 7:23 AM, Pierre Ossman wrote: Suggested patch. It does the following: - CUT block size changed to 64 pixels. This size in most cases has a CPU usage similar to 256 pixels, but a coverage more similar to 16 pixels. - Default compression level changed to 2. Based on your numbers, this seems to get us most of the compression, whilst avoiding most of the CPU usage (compared to level 3). - CUT enabled by default. Will be disabled if all clients advertise a compression level of 1 or below. compareFB=0 will forcefully disable it at all times. There is currently no way to enable it as well as have a low compression setting. Does this seem ok to you? Rgds -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance
On 11/17/11 12:43 PM, Pierre Ossman wrote: Because it's a boolean. It has just the states true or false. There is no mechanism to see if the user didn't bother specifying anything (and I'm not sure that's desirable anyway). So we cannot map our three states to it (always on, always off, auto). We could turn it into an int instead and have different values meaning different things. But I'm not sure it's worth it. I think it would be worth it to have on, off, and auto. We always want to offer the user the ability to override our decisions. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Low-level ComparingUpdateTracker performance
On 11/16/11 5:25 AM, Pierre Ossman wrote: JPEG quality level 1 is not what I'm considering a reasonable WAN setting, so I'm not sure how realistic these numbers are. Still, I think my conclusions are roughly the same. Well, then, what are you considering to be appropriate WAN settings? When my users connect over a 5 Mbps link, they will typically dial down the quality in TurboVNC to the Low-Quality JPEG preset and then use automatic lossless refresh to send a lossless image during periods of inactivity. This is the only way to get interactive frame rates with 3D applications over such a connection. Your sheet has a bug in it so you're comparing the wrong cells. It referenced the G column instead of the O column. The bandwidth savings are about the same for both compression levels. This also means the CPU overhead was exaggerated. Sorry about that. So ignore my comments regarding CL=3. The relative B/W and speedup were not far off from the CL=1 tests. Maybe. Given your current numbers, this might make some sense. But since the JPEG quality is unrealistically low (IMO), the numbers are currently showing off the CUT at its worst. I don't know how you justify that statement. I tested both a low-quality and high-quality JPEG scenario and reported both. This also made me take another look at the compression setting. I have to admit I might have read through your previous report a bit too hastily. This new one had more data though, which allowed a more detailed analysis. Looking at the first few tests (the normal applications), the bandwidth savings of dialing up the compression is somewhere around 20%. CPU usage varies, but seems to be roughly that for every percentage bandwidth saved, you lose the same percentage of CPU. The 3D applications fare worse, getting generally less savings and eating more CPU. Given this, I'm no longer convinced that having a default compression level of 1 is so clear cut. Normal usage seems to have quite a bit of potential gain here. Here are the relative compression ratios and speedups for the 2D datasets when moving from CL=1 to CL=2 (I will add these numbers to the next iteration of the spreadsheet): bugzilla: -6.1% CR, -1.1% speedup compilation:-19% CR, 3.1% speedup bars: -1.6% CR, -8.1% speedup kde-hearts-16: -0.46% CR, -2.2% speedup freshmeat: -4.9% CR, -4.3% speedup slashdot: -6.7% CR, -25% speedup photos: -0.63% CR, 4.9% speedup kde-hearts-24: -0.39% CR, -3.3% speedup The 3D apps almost always suffer a much worse speedup (in the range of 10-20%) with very little gain in compression ratio. CL=1 is definitely the most efficient compression level in terms of CPU usage. We could, but we generally would like not to. We prefer if our goals align with the upstream projects we use. There is less friction when it comes to long term plans that way, and having our users running basically the same product as the project's users benefits both when it comes to finding and fixing bugs. I'm trying hard not to laugh. Let's be realistic-- besides Cendio, Brian and I are the only ones doing any significant development in recent months. Thus, I'm not sure we really have an upstream project here. It seems like the project goals are largely what Cendio wants them to be, and friction arises whenever someone (usually me) disagrees with that. And I'd argue the opposite that users should indicate that they are in an environment where bandwidth is of little relevance and that CPU usage should be prioritised. Bug again, this boils down to which users we are targeting for TigerVNC. Yes, you should talk to your marketing department about this, since they are the ones who hired me to make TigerVNC into a TurboVNC replacement. If that was never the goal, then I need to reset my expectations regarding this project. Let's be very clear. Cendio is not looking for a direct replacement of TurboVNC. Our hopes for TigerVNC is for it to become the standard VNC Again, talk to your marketing department, as I was told otherwise. If you aren't looking to replace TurboVNC, then the question becomes whether it is best for The VirtualGL Project to work within the confines of the TigerVNC Project or whether I should just move forward within my own project. I don't want to invest any more significant time in a project that will ultimately be moving in a direction that is not aligned with the goal of achieving peak performance for 3D apps. implementation, appealing to a very broad range of users. LAN users, including high-performance 3D users, are certainly a part of this. But it is not our belief that they are the majority and the project should by default be geared towards more average users. That means applications such as Firefox and LibreOffice generally carry more weight than Catia or Maya. I don't believe that there are generally one golden set of configuration parameters that can make everyone
[Tigervnc-devel] Low-level ComparingUpdateTracker performance
The attached spreadsheet shows the low-level performance effects of enabling and disabling the CUT, as well as the effect of changing its block size to 256 x 256 instead of the default of 16 x 16. Tests were performed both with typical LAN settings (compress level=1/quality level=8) and WAN settings (compress level=3/quality level=1 and compress level=1/quality level=1.) What I observe is that enabling the CUT with compress level=1 only shows a significant low-level improvement for a few 2D tests: bugzilla (web browsing): 57% B/W reduction with LAN settings 42% B/W reduction with WAN settings kde-hearts (manipulating file manager windows in KDE): 31% B/W reduction with LAN settings 17% B/W reduction with WAN settings photos (viewing a photo in GIMP): 40% B/W reduction with LAN settings 22% B/W reduction with WAN settings The improvement is greatly reduced as the JPEG quality is reduced. This makes sense, because with lower-quality JPEG, less bandwidth is required for each rectangle, on average, and thus the bandwidth that one can save by enabling the CUT is reduced, on average. For the other 2D tests, only a modest (~5-10%) bandwidth reduction was observed with compress level=1. For the 3D tests, no significant bandwidth reduction was achieved with compress level=1 (not surprising at all), but enabling the CUT decreased the performance by very significant amounts (as much as 45% reduction in throughput with the LAN settings.) That is definitely unacceptable, since 3D apps are performance-critical. I would argue that a 45% reduction in frame rate for a user of a CAD application on a LAN is going to make a much larger impact in their ability to use the app than would a 45% reduction in Firefox's update rate on a WAN. Increasing the CUT block size to 256 x 256 improved matters-- surprisingly, no loss in bandwidth was observed relative to the 16 x 16 tests, and now the 3D tests slowed down by a max. of 26% when enabling the CUT with LAN settings. Still an unacceptable slow-down, but better. The CUT made a much larger difference in bandwidth with compress level=3. In this case, even some of the 3D datasets realized some significant reduction in bandwidth, but the performance hit from enabling the CUT was larger across the board as well. Here's what I would recommend for now: (1) Change BLOCK_SIZE to 256. This didn't seem to have any effect on compression ratio, and it improved performance significantly whenever the CUT was enabled. Pierre, could you re-run your high-level tests to verify that this has no ill effects at that level, either? (2) Enable the CUT by default only when compress level 1. Disable it by default for compress level = 1. The compress level and quality level are designed precisely so that users can make such bandwidth vs. CPU usage trade-offs as this. The default TigerVNC settings are appropriate for LAN use, in which the benefits of the CUT do not outweigh the performance costs. This is a compromise that I would hope would make both parties happy for now. The CUT still needs optimizing, because even with the larger block size, the relative loss in throughput for 2D apps often exceeds the relative reduction in bandwidth. I could easily conceive of scenarios in which applications that were bandwidth-limited with the CUT disabled would become CPU-limited with it enabled. If Cendio wants the CUT always enabled for their product, then that is easily accomplished by modifying the vncserver startup script, which I assume is something they already do. I do not think that enabling it by default for the open source product is appropriate unless the user sets compress level 1, indicating that they are in an environment in which reducing bandwidth is more likely to improve performance than reducing CPU usage. lowlevelcutperf.ods Description: application/vnd.oasis.opendocument.spreadsheet -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Reenabling the comparing update tracker (CUT)
as tuned for LANs at the expense of everything else is not our goal. The defaults should reflect the needs of the majority of users. We're trying to create a well-rounded VNC implementation that can be used for a broad range of applications, not just Understood, which is why I proposed to enable the CUT by default in situations where it can be proven more beneficial than not (maybe in situations where the server detects that link usage is maxed out?) More study is warranted. I know that enabling it by default will hurt performance for the apps and deployment scenarios that are most important to VirtualGL. Thus, it would be nice if we could come up with an automatic mode that makes us both happy. Why? I'd argue the opposite. It's should only be disabled when it is clear that it is the limiting factor. For many (most?) users, that limiting factor will be bandwidth, not CPU. And there is also the fact that there is a good enough I, namely when it is no longer possible for the user to tell the difference. Bandwidth is generally always worth reducing. Sorry, but you're wrong. In most VirtualGL deployment scenarios, CPU usage is the primary constraint to performance. On a 1920x1200 desktop, you can really only get 15 fps on modern hardware, and even a few fps drop is noticeable at that level. My customers are, with great success (evidenced by our Red Hat Innovator of the Year Award) using TurboVNC as a replacement for local workstations. WAN performance is less important to them than absolute peak LAN performance, but again, I argue that there's probably a way to automatically detect when it would likely be beneficial. These numbers are way too big to ignore. And given that the CUT used to be enabled (i.e. this is a regression), and that I have yet to see an installation where server side CPU was such a major issue that bandwidth can be ignored, I say we should revert to the 1.1.0 behaviour. From the point of view of TurboVNC customers, who Cendio is hypothetically trying to attract by hiring me to enhance TigerVNC's performance, decreased frame rate and increased server CPU usage would be viewed as a regression relative to TurboVNC and would hinder adoption of TigerVNC in that market. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Reenabling the comparing update tracker (CUT)
I have hundreds of users using TurboVNC (which doesn't have a CUT) with dual 1920x1200 displays, and CPU is definitely the primary limitation. They are not having issues with bandwidth. What I'm saying is that we should not have a knee-jerk reaction to this or to decide based on only one or two apps. This needs to be studied at the low level. I know for a fact that the CUT kills performance for 3D and video apps. Pierre, more specifically, Cendio hired me to improve the performance of TigerVNC, and it doesn't make sense to then reverse some of that hard-fought gain. Will discuss further when I'm back in the office. On Nov 11, 2011, at 8:54 AM, Brian Hinz bph...@users.sourceforge.net wrote: Initially I would have agreed completely with DRC since 95% of my users are on GbE fiber, but if those numbers accurately reflect typical usage (and it would seem they do) then I have to wonder how this might affect throughput. It's been a while since the last time I tried to quantify this (6 months), but I know that when I did I was surprised at how low the overall bandwidth usage was for 50+ users (all with large displays, =1920x1200). If nothing else, can this be made to be a runtime option? -brian On Fri, Nov 11, 2011 at 5:48 AM, Pierre Ossman oss...@cendio.se wrote: On Thu, 10 Nov 2011 13:40:38 -0600 DRC dcomman...@users.sourceforge.net wrote: Sorry, but I've quantified the reasons why it should be disabled on a LAN. If you see some benefit in performance on a WAN, then you need to quantify that as well. I will not endorse TigerVNC unless it is performant by default. I'm sorry you feel that way as tuned for LANs at the expense of everything else is not our goal. The defaults should reflect the needs of the majority of users. We're trying to create a well-rounded VNC implementation that can be used for a broad range of applications, not just LAN use. I'd also like to hear what other people think. Adam? Brian? Anyone else following this list? What use cases are your priority? The CUT uses a significant amount of server CPU time, so if it benefits WAN-based scenarios, it needs to be quantified how much and how much of a CPU time hit is incurred from the LAN-based scenarios. If it benefits only one and not the other, then the default behavior needs to be enabling it only when it shows a clear benefit without compromising overall frame rate. Why? I'd argue the opposite. It's should only be disabled when it is clear that it is the limiting factor. For many (most?) users, that limiting factor will be bandwidth, not CPU. And there is also the fact that there is a good enough framerate, namely when it is no longer possible for the user to tell the difference. Bandwidth is generally always worth reducing. But you want some numbers, so I did some quick measurements: Firefox, msn.com, 10 seconds with a blinking cursor and animated preview: With comparing: 1.3 MiB to 2.4 MiB Without comparing: 3.8 MiB to 7.5 MiB Bandwidth savings: 66-68% Firefox, idg.se, 10 seconds with an animated GIF banner ad: With comparing: 420 KiB to 450 KiB Without comparing: 12 MiB to 16 MiB Bandwidth savings: 96-97% Compositing, gnome-terminal, 10 seconds with mostly just empty space and blinking cursor: With comparing: 30 KiB Without comparing: 501 KiB Bandwidth savings: 94% Compositing, gnome-terminal, 10 seconds with a fair amount of text present and blinking cursor: With comparing: 100 KiB Without comparing: 1.7 MiB Bandwidth savings: 96% These numbers are way too big to ignore. And given that the CUT used to be enabled (i.e. this is a regression), and that I have yet to see an installation where server side CPU was such a major issue that bandwidth can be ignored, I say we should revert to the 1.1.0 behaviour. More work on the CUT is of course worthwhile. Perhaps it should have some heuristic on automatically turning it on and off based on the availability of CPU? But where we stand right now, having it off is a worse trade-off than having it on. IMO. 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? -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc
Re: [Tigervnc-devel] Reenabling the comparing update tracker (CUT)
Sorry, but I've quantified the reasons why it should be disabled on a LAN. If you see some benefit in performance on a WAN, then you need to quantify that as well. I will not endorse TigerVNC unless it is performant by default. The CUT uses a significant amount of server CPU time, so if it benefits WAN-based scenarios, it needs to be quantified how much and how much of a CPU time hit is incurred from the LAN-based scenarios. If it benefits only one and not the other, then the default behavior needs to be enabling it only when it shows a clear benefit without compromising overall frame rate. On Nov 10, 2011, at 8:08 AM, Pierre Ossman oss...@cendio.se wrote: On Thu, 10 Nov 2011 07:33:58 -0600 DRC dcomman...@users.sourceforge.net wrote: Strongly object. The performance hit by turning it on is severe and not something that can just be optimized away. My testing shows that the CUT is almost never used. Firefox is hardly something that is almost never used. Compositing is also something that is very popular in modern desktop systems. I'd like to see how much it can improve things with Unity 2D for example. I'd say that the majority of users will benefit from this feature being turned on. It should therefore be turned on by default, and the people who don't need it can turn it off. 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? -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] tight decoded broken in trunk
It probably needs to be w * sizeof(PIXEL_T), but I'd feel better if
someone could test it, as apparently whatever I'm doing isn't invoking
the copy filter (not sure how that filter is ever invoked, because I'm
exercising all of the others by running various programs in the Xvnc
session, moving windows around, etc.) If you have a reliable way of
testing the Copy filter, then you should be able to invoke the code
below by running vncviewer on an X server with a depth of 16.
On 11/9/11 3:23 AM, matthieu.lochegn...@altissemiconductor.com wrote:
DRC dcomman...@users.sourceforge.net wrote on 08/11/2011 19:37:33:
Odd that valgrind didn't trap it. Perhaps the low-level datasets aren't
ever exercising the Tight Copy filter.
Hi,
are you confident with the few lines for the Tight Copy filter, below
Pierre's fix?
Those were changed this way by commit 4763 :
while (h 0) {
- input-readBytes(ptr, rowSize);
+ memcpy(ptr, srcPtr, rowSize * sizeof(PIXEL_T));
ptr += stride;
+ srcPtr += w * sizeof(PIXEL_T);
h--;
}
I guess the new version does not copy the same number of bytes except in
8bpp.
Maybe this could be written :
while (h 0) {
memcpy(ptr, srcPtr, w * sizeof(PIXEL_T));
ptr += stride;
srcPtr += w * sizeof(PIXEL_T);
h--;
}
or :
while (h 0) {
memcpy(ptr, srcPtr, rowSize);
ptr += stride;
srcPtr += rowSize;
h--;
}
--
Matthieu Lochegnies
Altis Semiconductor - http://www.altissemiconductor.com/
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [PATCH] Fix latency issue
Can you explain what all of the fence stuff is doing? Also, why is there both a CU message (which uses the registered number of 150) and a CU pseudo-encoding? On 11/9/11 3:41 AM, Pierre Ossman wrote: Here is the promised patch to fix the latency issue in VNC. The basic idea is to let the server start sending updates without requests, but doing so in a way that doesn't overload the client or the network. WARNING! This patch uses protocol numbers that aren't properly registered and should therefore not be deployed anywhere! Rgds -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] tight decoded broken in trunk
On 11/9/11 1:15 PM, matthieu.lochegn...@altissemiconductor.com wrote: I ran into it when using Xvnc from the RHEL6 package: tigervnc-server-1.0.90-0.10.20100115svn3945.el6.x86_64. I just did what you told: I started a Xvnc with depth 16, displayed on it a terminal (with a window manager), and just moved the window with the vncviewer. Very mysterious. Hoping someone else can shed some light on it. As far as I can tell, our code never sends that pseudo-encoding. It only decodes it in the viewer (same as gradient encoding-- we decode that as well but never send it.) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] New pre-release build
http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases -- Contains my client-side performance optimizations -- Contains numerous Java viewer fixes -- Windows code is now built with MinGW -- NLS theoretically works with the 32-bit Windows vncviewer, (if you were to install the .mo files under c:\program files\tigervnc\share\locale-- To do: figure out how to make that happen in the installer in a straightforward manner) -- Contains Pierre's latest optimizations for high-latency networks -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] New pre-release build
I have re-spun the build to add Pierre's Tight decoder bug fix and other enhancements from today On 11/8/11 4:17 AM, DRC wrote: http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases -- Contains my client-side performance optimizations -- Contains numerous Java viewer fixes -- Windows code is now built with MinGW -- NLS theoretically works with the 32-bit Windows vncviewer, (if you were to install the .mo files under c:\program files\tigervnc\share\locale-- To do: figure out how to make that happen in the installer in a straightforward manner) -- Contains Pierre's latest optimizations for high-latency networks -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Broken official (legacy-friendly) build caused by enabling DPMS extension
On 11/7/11 2:44 AM, Peter Åstrand wrote: Wrt DRI: I must admit that I don't fully understand how it works, but at least for Xorg server 1.5, DRI1 is not necessary for GLX, but DRI2 is, it seems. We are building with these flags: That was the clue I needed. Apparently it wasn't properly detecting DRI2 support because the dri2proto package downloaded by build-xorg was too old for xorg-xserver-1.6.5. Upgrading dri2proto seems to have fixed it. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] Broken official (legacy-friendly) build caused by enabling DPMS extension
As mentioned in the previous post, r4745 (activating the DPMS extension) broke our official project build, because of the following scenario: r4745 removes -DNO_HW_ONLY_EXTS from Xvnc_CPPFLAGS in unix/xserver/hw/vnc/Makefile.am. This causes xorg-xserver 1.6.5 to attempt to build the XFree86-DRI extension, but the stub for XFree86DRIExtensionInit() is missing, so the build fails. Adding --disable-dri to the Xorg config flags, as I attempted to do in r4765, doesn't work, because DRI is necessary to provide software OpenGL rendering. Attempting to add -UXD86DRI to Xvnc_CPPFLAGS in unix/xserver/hw/vnc/Makefile.am does not work, either, because xorg-config.h, which is included by miinitext.c, overrides it. I am not a big fan of faking the extension, that is, of creating an artificial stub for XFree86DRIExtensionInit(), because it would lead to a situation in which the extension was listed as available but was horribly broken. However, the only other solution I can concoct is patching the configure.ac file in the X server so that it avoids #defining XF86DRI in xorg-config.h but keeps DRI alive otherwise. Not a huge fan of that, either, since we don't really know which versions of the X server this affects. Any ideas on how to resurrect our official project builds? DRC -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] TigerVNC Viewer Performance Enhancements
I have completed the TigerVNC Viewer optimization project, and the latest revision of TigerVNC (r4764) should, unless I am totally missing something, perform on parity with TurboVNC end-to-end (barring the use of multi-threading in the latter, and assuming a sufficiently fast client machine-- see below.) The project was not as difficult as optimizing the server, since it was not necessary to make any protocol changes, but it still required many hours of low-level analysis using VNCBenchTools. I also performed a full high-level benchmark run with the Linux viewer (64-bit and 32-bit) and sanity checked the performance of the OS X and Windows viewers. All appear to be producing the same frame rate (even slightly better in a couple of cases) than TurboVNC when using the GLXspheres benchmark and VirtualGL. At the low levels, decoder performance was improved by 15-20% across the board relative to the TigerVNC 1.1 baseline, measured against the set of 20 canonical RFB session captures described in http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf. This low-level improvement translated into an aggregate throughput improvement of 15-20% at the high level as well, bringing the aggregate performance up to TurboVNC's baseline. The only remaining anomaly is that the TigerVNC Viewer, at least the Linux version, still produces quite a bit more CPU usage on the client machine than the TurboVNC Viewer. This did not cause a slow-down on my system, because the client CPU cores were still only about 65% engaged (as opposed to 47% engaged with TurboVNC.) However, theoretically, this could cause TigerVNC to perform more slowly than TurboVNC on a single-core machine or a slower multi-core machine. Both the vncviewer and Xorg processes use more of the CPU in TigerVNC than in TurboVNC. The increased usage may be due to a difference in architecture. One thing I noticed at the low level was that a significant amount of CPU time was being spent in the rectangle fill routines, because the TigerVNC Viewer uses the CPU to fill solid regions of its back buffer. TurboVNC, by contrast, cheats and does a sort of pseudo-double-buffering, whereby it will wait until all of the rectangles from a framebuffer update have been received, then it will call XFillRectangle() and XShmPutImage() in rapid succession to draw the solid and non-solid rectangles, respectively, then XSync() to flush everything to the screen. The sequence of X calls occurs so quickly that it is perceived as double buffering, even though technically it isn't, and since the XFillRectangle() calls can be offloaded to hardware, they don't cause a significant load on the X server. I have optimized the rectangle fill routines in TigerVNC somewhat, but the X11 usage is still different, since TigerVNC will use XShmPutImage() to draw everything to the screen, rather than using XFillRectangle() for the solid regions and XShmPutImage() for everything else. I'm not suggesting that TigerVNC adopt TurboVNC's method, but I'm hoping to perhaps spark ideas regarding how to improve the rectangle fill performance in TigerVNC, if that is in fact the cause of the CPU usage increase. I wish I had a build to share with you, but the pre-release build is broken right now, due to the DPMS changes that were checked in earlier. Looking into it. DRC -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4739] rfbproto/rfbproto.rst
I personally have no problem with this change, but I just wanted to note that the names are listed as TurboVNC blah blah blah in the official upstream RFB spec, so this change causes our spec to differ from the upstream one. Don't know if that's a problem or not. On 10/27/11 7:12 AM, ossm...@users.sourceforge.net wrote: Revision: 4739 http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4739view=rev Author: ossman_ Date: 2011-10-27 12:12:32 + (Thu, 27 Oct 2011) Log Message: --- Use a more generic name for these encodings as they have a broad (possible) use. Signed-off-by: Pierre Ossman oss...@cendio.se Modified Paths: -- rfbproto/rfbproto.rst Modified: rfbproto/rfbproto.rst === --- rfbproto/rfbproto.rst 2011-10-27 12:07:05 UTC (rev 4738) +++ rfbproto/rfbproto.rst 2011-10-27 12:12:32 UTC (rev 4739) @@ -792,9 +792,9 @@ -256``TGHT`` ``COMPRLVL`` `Compression Level Pseudo-encoding`_ -305``GGI_`` ``GII_`` `gii Pseudo-encoding`_ --512``TRBO`` ``FINEQLVL`` `TurboVNC Fine-Grained Quality Level +-512``TRBO`` ``FINEQLVL`` `JPEG Fine-Grained Quality Level Pseudo-encoding`_ --768``TRBO`` ``SSAMPLVL`` `TurboVNC Subsampling Level +-768``TRBO`` ``SSAMPLVL`` `JPEG Subsampling Level Pseudo-encoding`_ === === === === @@ -1937,8 +1937,8 @@ -307 `DesktopName Pseudo-encoding`_ -308 `ExtendedDesktopSize Pseudo-encoding`_ -309 `xvp Pseudo-encoding`_ --412 to -512 `TurboVNC Fine-Grained Quality Level Pseudo-encoding`_ --763 to -768 `TurboVNC Subsampling Level Pseudo-encoding`_ +-412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_ +-763 to -768 `JPEG Subsampling Level Pseudo-encoding`_ == Other registered encodings are: @@ -2642,19 +2642,19 @@ image quality you can expect. The quality level is also just a hint to the server. -TurboVNC Fine-Grained Quality Level Pseudo-encoding +JPEG Fine-Grained Quality Level Pseudo-encoding +--- -The TurboVNC Fine-Grained Quality Level pseudo-encoding allows the image +The JPEG Fine-Grained Quality Level pseudo-encoding allows the image quality to be specified on a 0 to 100 scale, with -512 corresponding to image quality 0 and -412 corresponding to image quality 100. This pseudo-encoding was originally intended for use with JPEG-encoded subrectangles, but it could be used with other types of image encoding as well. -TurboVNC Subsampling Level Pseudo-Encoding --- +JPEG Subsampling Level Pseudo-Encoding +-- -The TurboVNC Subsampling Level pseudo-encoding allows the level of chrominance +The JPEG Subsampling Level pseudo-encoding allows the level of chrominance subsampling to be specified. When a JPEG image is encoded, the RGB pixels are first converted to YCbCr, a colorspace in which brightness (luminance) is separated from color (chrominance.) Since the human eye is more sensitive to This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Tigervnc-commits mailing list tigervnc-comm...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-commits -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4731] trunk/common/rdr
Let me explain something about quality control. When someone has spent
many dozens of hours debugging both the performance and stability of a
piece of code at the low level, then whenever you make sweeping changes
to it like this, it is incumbent upon you to either work with the person
who tested the code or to do the same testing yourself. Otherwise, you
have, by definition, de-stabilized the code.
Without knowing why you were experiencing issues, what you've done below
likely created more bugs than it fixed. This should have been re-tested
with vncbenchtools prior to checking it in.
On 10/18/11 9:27 AM, ossm...@users.sourceforge.net wrote:
Revision: 4731
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4731view=rev
Author: ossman_
Date: 2011-10-18 14:27:07 + (Tue, 18 Oct 2011)
Log Message:
---
Another attempt at solving the compression level change problems. We were
still
not detecting the correct approach properly, and hence still getting crashes.
Modified Paths:
--
trunk/common/rdr/ZlibOutStream.cxx
trunk/common/rdr/ZlibOutStream.h
Modified: trunk/common/rdr/ZlibOutStream.cxx
===
--- trunk/common/rdr/ZlibOutStream.cxx2011-10-14 21:35:40 UTC (rev
4730)
+++ trunk/common/rdr/ZlibOutStream.cxx2011-10-18 14:27:07 UTC (rev
4731)
@@ -23,27 +23,28 @@
#include zlib.h
+#undef ZLIBOUT_DEBUG
+
using namespace rdr;
enum { DEFAULT_BUF_SIZE = 16384 };
ZlibOutStream::ZlibOutStream(OutStream* os, int bufSize_, int compressLevel)
: underlying(os), compressionLevel(compressLevel), newLevel(compressLevel),
-bufSize(bufSize_ ? bufSize_ : DEFAULT_BUF_SIZE), offset(0),
-newBehavior(false)
+bufSize(bufSize_ ? bufSize_ : DEFAULT_BUF_SIZE), offset(0)
{
zs = new z_stream;
zs-zalloc= Z_NULL;
zs-zfree = Z_NULL;
zs-opaque= Z_NULL;
+ zs-next_in = Z_NULL;
+ zs-avail_in = 0;
if (deflateInit(zs, compressLevel) != Z_OK) {
delete zs;
throw Exception(ZlibOutStream: deflateInit failed);
}
ptr = start = new U8[bufSize];
end = start + bufSize;
- const char *version = zlibVersion();
- if (strcmp(version, 1.2.3) 0) newBehavior = true;
}
ZlibOutStream::~ZlibOutStream()
@@ -77,74 +78,39 @@
void ZlibOutStream::flush()
{
+ checkCompressionLevel();
+
zs-next_in = start;
zs-avail_in = ptr - start;
-//fprintf(stderr,zos flush: avail_in %d\n,zs-avail_in);
+#ifdef ZLIBOUT_DEBUG
+ fprintf(stderr,zos flush: avail_in %d\n,zs-avail_in);
+#endif
- if (!underlying)
-throw Exception(ZlibOutStream: underlying OutStream has not been set);
+ // Force out everything from the zlib encoder
+ deflate(Z_SYNC_FLUSH);
- while (zs-avail_in != 0) {
-
-do {
- underlying-check(1);
- zs-next_out = underlying-getptr();
- zs-avail_out = underlying-getend() - underlying-getptr();
-
-//fprintf(stderr,zos flush: calling deflate, avail_in %d, avail_out
%d\n,
-//zs-avail_in,zs-avail_out);
- checkCompressionLevel();
- if (zs-avail_in != 0) {
-int rc = deflate(zs, Z_SYNC_FLUSH);
-if (rc != Z_OK) throw Exception(ZlibOutStream: deflate failed);
- }
-
-//fprintf(stderr,zos flush: after deflate: %d bytes\n,
-//zs-next_out-underlying-getptr());
-
- underlying-setptr(zs-next_out);
-} while (zs-avail_out == 0);
- }
-
offset += ptr - start;
ptr = start;
}
int ZlibOutStream::overrun(int itemSize, int nItems)
{
-//fprintf(stderr,ZlibOutStream overrun\n);
+#ifdef ZLIBOUT_DEBUG
+ fprintf(stderr,zos overrun\n);
+#endif
if (itemSize bufSize)
throw Exception(ZlibOutStream overrun: max itemSize exceeded);
- if (!underlying)
-throw Exception(ZlibOutStream: underlying OutStream has not been set);
+ checkCompressionLevel();
while (end - ptr itemSize) {
zs-next_in = start;
zs-avail_in = ptr - start;
-do {
- underlying-check(1);
- zs-next_out = underlying-getptr();
- zs-avail_out = underlying-getend() - underlying-getptr();
+deflate(Z_NO_FLUSH);
-//fprintf(stderr,zos overrun: calling deflate, avail_in %d,
avail_out %d\n,
-//zs-avail_in,zs-avail_out);
-
- checkCompressionLevel();
- if (zs-avail_in != 0) {
-int rc = deflate(zs, 0);
-if (rc != Z_OK) throw Exception(ZlibOutStream: deflate failed);
- }
-
-//fprintf(stderr,zos overrun: after deflate: %d bytes\n,
-//zs-next_out-underlying-getptr());
-
- underlying-setptr(zs-next_out);
-} while (zs-avail_out == 0);
-
// output buffer not full
if (zs-avail_in == 0) {
@@ -166,23 +132,69 @@
return nItems;
}
+void ZlibOutStream::deflate(int flush)
+{
+ int rc;
+
+ if
Re: [Tigervnc-devel] Visual Studio or not
On 10/7/11 2:35 AM, Peter Åstrand wrote: For the record, I did try this 2 years ago, with the patch you and Pierre submitted upstream to MinGW. It compiled but did not link. So why didn't you report this? I cannot found anything about this, neither in the tracker nor on the mailinglist. The patch apparently worked fine for Adam and it worked fine for us. I mentioned it several times on the list, in the context of our discussions regarding moving to CMake for Windows, regarding the autotools performance problem on Windows, etc. Don't know how the patch could have possibly worked fine, since it did not apparently add anything to the link libraries-- or, if it did, that portion was apparently not accepted by MinGW. Well, curiously, apparently that patch made it into MinGW64, and I just tried again with that compiler-- same result. Compiles but does not link, because the stub is not in libuuid. Never heard of such a problem. Can you please give us the technical details? Which missing symbol, which error message... Why don't you try building it on a recent version of MinGW64 (it's probably reproducible using MinGW64 for Linux) and see for yourself? That was why we, as a team, decided it was necessary to continue supporting Visual Studio. This is not what I remember. I thought we just waited for MinGW to accept the patch. When we had this discussion before, we discussed the fact that they had rejected the patch, but apparently they did eventually accept the header portion of it. Interestingly, your new patch to libos does work with MinGW32, but now it interferes with the broken patch in MinGW64. How does it interfere? Please give us the technical details. Doesn't compile. The headers interfere. Again, try it for yourself. I'm not in a mood to be helpful to you right now. For every piece of Win32 functionality I need that isn't supported in MinGW, now I'm faced with MinGW contains most of the Win32 functionality one needs. Especially if you want to keep supporting older versions of Windows, which I suppose we want. We don't want a WinVNC or vncviewer which only works on Windows 7+. I thought you had the same goals, since you have been working on supporting platforms such as RHEL4? Peter, you have a real talent for twisting words around. Supporting Windows 7 does not mean that the code only works on that platform. It means that, perhaps, it may be necessary to conditionally use APIs on that platform to make WinVNC work properly. Then again, maybe that platform can be supported via simple bug fixes. Until WinVNC is working fully on W7, I am unwilling to paint myself into a corner and make it difficult to use any advanced functionality that might need to be used. Further, do you not realize that, after you have stated your case, there is no purpose to continuing to re-state and re-spin it? I have already come to a professional decision on this based on the relevant facts and my years of experience as a Windows developer. Unless you are going to provide any new information, then there is nothing to be gained by continuing this discussion. There is certainly nothing to be gained by engaging in ad hominem attacks, other than making me angry, which you have succeeded in doing. (a) reverse-engineering a stub for it Writing a short text file using the MSDN documentation is hardly reverse-engineering. Just as a for-instance, DEFINE_GUID(CLSID_ActiveDesktop,0x75048700L,0xEF1F,0x11D0,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); DEFINE_GUID(IID_IActiveDesktop,0xF490EB00L,0x1240,0x11D1,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); is not anywhere in the MSDN documentation and, in fact, appears to have been pretty much blindly copied from the Microsoft header files. I am certain that the MinGW Project has discussions regarding potential dangers of IP infringement whenever new interfaces are added, and I know they discussed such things in the context of the ActiveDesktop patch. I would be uncomfortable putting new, non-obvious Win32 interface code into TigerVNC without a similar vetting process, and our project is really not in the position to do that vetting. (b) writing a CMake compile and link test to verify that it isn't in MinGW What's the problem? Writing CMake (or Autotool) tests is the standard approach when using functionality that is not guaranteed to work on all platforms. This is the approach we are using for UNIX as well, remember. You're confusing the issue, Peter. When we write platform checks, platform typically means a particular O/S configuration. Few people would be on board with, for instance, depending on a particular piece of functionality in GCC that was broken in some releases. and, if so, that the MinGW version isn't broken, This is seldom. The MS compilers also has bugs. ?! That argument doesn't even make sense. We're talking about Windows functionality that is not supported or partially supported in MinGW. We're not
Re: [Tigervnc-devel] Visual Studio or not
On 10/6/11 2:50 AM, Peter Åstrand wrote: Remind me, which functionality is missing if you build without Visual Studio? WinVNC. It's always been WinVNC. It seems to me that instead of wasting time on maintaining multiple tool chain, you could invest that time in streamlining the GCC based one. I think we should stop using Visual Studio. From the start my position has been that multiple tool chains will mean trouble. I accepted that approach however since I understood that you wanted it that way, but since you are now telling us that you are unhappy with the current situation, perhaps it's time to through Visual Studio out. Forcing everybody to use Visual Studio is not an option. I wanted it that way?! Peter, you have a somewhat strange memory. Did I not just say in my previous message that I would be happy to abandon Visual Studio if we could get away with it? The reason we can't is because of WinVNC. We can't build WinVNC on MinGW because MinGW lacks the necessary API's, and the necessary API's were rejected upstream. This is about to become even more of a problem, because I'm being contracted by another company to improve WinVNC so that it can be used on Vista and W7, and that may yet require the use of more APIs that aren't supported in MinGW. It has nothing to do with streamlining. It has to do with the fact that MinGW will always be playing catch up with Microsoft, and some of the Microsoft API's can't be included because of IP concerns. Thus, there will always be certain functionality that can't be leveraged through the MinGW toolchain. It just so happens that some of that functionality is necessary to make WinVNC work. The basic facts of this case are the same as they were 2 years ago: we cannot abandon Visual Studio without abandoning WinVNC, and we cannot abandon WinVNC without effectively forking TigerVNC, since WinVNC depends on a lot of the same infrastructure as Xvnc, not to mention integrates the same Java viewer, etc. Yet, if you'll recall, I was the one who proposed exactly such a fork about 3 months ago, and Cendio decried the idea, and ultimately I agreed with your reasoning. There is interest in the community for a more high-performance WinVNC, and the most expedient path forward to that is to leverage my previous work in optimizing the TigerVNC encoder. Otherwise, I would have to do a similar overhaul to TightVNC 2.0.x or some other WinVNC code base, which I don't relish-- both because it would require a similar 100-hour effort to re-invent TigerVNC's wheel and also because it would create yet another fork. Besides, let's back up a minute-- the modification that broke the Visual Studio build was in FLTK. The FLTK Project supports Visual Studio as one of their build chains, so someone was going to have to fix the build eventually in order for it to be accepted upstream. I assume that upstream acceptance is the ultimate goal for these FLTK patches. Thus, I believe that it is quite reasonable to expect that whoever is developing the FLTK patches test them on the compilers that the FLTK Project supports. Every minute you guys spend arguing with me is a minute less that I have to spend on optimizing the VNC Viewer or doing other things that are supposed to be a priority, so I'll let you decide whether it's worth it to continue this discussion. Personally, I don't think it is. We have a requirement to support Visual Studio as long as we have a requirement to support WinVNC. I don't think my request was in any way unreasonable. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
On 10/6/11 4:48 AM, Peter Åstrand wrote: Yes, but what is the problem with WinVNC? Nevermind, I looked back at the discussions myself. It's the problem with IActiveDesktop missing from the MinGW distro. IMHO, this is not unsolvable. If MinGW still refuses to add support for this, we should be able to include the missing definitions in the TigerVNC code base. It's not just missing definitions. The patch you guys tried to commit upstream didn't work, because it did not include support for IActiveDesktop in the actual link libraries. AFAIK, including such support would require back-engineering the Windows libs, which is why MinGW rejected the idea. Here's an offer: If we fix so that WinVNC can be built with a standard MinGW distribution, can we then remove support for Visual Studio? Assuming you could fix WinVNC in its current incarnation, my main concern would still be that you would be painting me into a corner, whereby I couldn't use any other advanced functionality if I needed it in the future. Plus, I think it's probably a moot point, because I'm doubtful that anyone can make WinVNC work with MinGW, even in its current incarnation. One alternative might be to set up a separate CMake project for WinVNC under win/. Then we'd only have to worry about VStudio support for the portions of the common libs that it depends on, which would of course not include FLTK or most of the other stuff that Cendio most often touches. Someone has already proposed separating librfb into client and server flavors, which would reduce the dependencies even further. WinVNC could be completely self-contained, with its own separate installer, etc., and all of the MSVC logic could be moved out of the main build system and into this sub-project. Given that solution, I would be fine with requiring MinGW to build VNCViewer. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Visual Studio or not
Wow, Peter. So condescending. If I was in any mood to compromise before, I'm certainly not now. For the record, I did try this 2 years ago, with the patch you and Pierre submitted upstream to MinGW. It compiled but did not link. Well, curiously, apparently that patch made it into MinGW64, and I just tried again with that compiler-- same result. Compiles but does not link, because the stub is not in libuuid. That was why we, as a team, decided it was necessary to continue supporting Visual Studio. Interestingly, your new patch to libos does work with MinGW32, but now it interferes with the broken patch in MinGW64. Do you see where this is going? For every piece of Win32 functionality I need that isn't supported in MinGW, now I'm faced with (a) reverse-engineering a stub for it, (b) writing a CMake compile and link test to verify that it isn't in MinGW and, if so, that the MinGW version isn't broken, and (c) conditionally using either the MinGW version of the header (if it exists) or our header and conditionally linking the MinGW version (if it exists) or our version. That isn't exactly an efficient development model. You need to understand that my lack of comfort with MinGW is dictated by the somewhat hackish approach necessary to get stuff like the above to work. Enterprise-quality software is not built by hacking. I also understand your lack of comfort with Visual Studio. You haven't used it continuously for 15 years like I have. I'm not saying that you're wrong-headed for being uncomfortable with Visual Studio, but neither should you say I'm wrong-headed for being uncomfortable with MinGW. Comfort level is very important when developing something. I don't want to feel like I have to patch libos every time I use something that MinGW doesn't have, and I don't want to have to maintain build tests for any advanced functionality to determine whether or not it's present or broken in MinGW. I feel like I've been more than reasonable and willing to compromise about this. As the one who's going to be developing WinVNC, I need to feel like I'm free to do what I need to do to make it work for my customer, and I am not comfortable using MinGW for WinVNC at this time. Once things are working properly on W7 and Vista, then we can re-evaluate. In the meantime, your choices are to accept my compromise or to keep things the way they are. Personally, I think that splitting WinVNC into its own sub-build has other advantages as well, irrespective of the choice of compiler, and I like the idea of having separate installers for server and viewer. On 10/6/11 9:31 AM, Peter Åstrand wrote: On Thu, 6 Oct 2011, DRC wrote: IMHO, this is not unsolvable. If MinGW still refuses to add support for this, we should be able to include the missing definitions in the TigerVNC code base. It's not just missing definitions. The patch you guys tried to commit upstream didn't work, because it did not include support for IActiveDesktop in the actual link libraries. AFAIK, including such support would require back-engineering the Windows libs, which is why MinGW rejected the idea. It seems that you have misunderstood how build time linking of Windows binaries works. You don't actually need the full library; only a stub. This stub can be generated with dlltool, typically from a .def file. In the case of the ActiveDesktop constants though, you also need to have a small .c file containing 2 rows of DEFINE_GUID. MinGW hasn't yet accepted the patch because one single constant (IID_IActiveDesktop ) cannot be found in the registry or the MS documentation on MSDN. Instead, a binary was used to retrieve the value. They haven't used that approach before. (The constant can now also be found on http://social.msdn.microsoft.com.) Here's an offer: If we fix so that WinVNC can be built with a standard MinGW distribution, can we then remove support for Visual Studio? Assuming you could fix WinVNC in its current incarnation, my main concern would still be that you would be painting me into a corner, whereby I couldn't use any other advanced functionality if I needed it in the future. Plus, I think it's probably a moot point, because I'm doubtful that anyone can make WinVNC work with MinGW, even in its current incarnation. Could you please stop saying that things are close to impossible without even trying? Attached is a patch that adds the missing definitions to the internal libos, if necessary. With this patch, building WinVNC with MinGW seems to work fine. If you would need any advanced functionality in the future, you can just add the missing constants and/or stubs, just as I did. This is typically very straight forward. We have been using MinGW for almost 10 years, and with the exception of this ActiveDesktop COM stuff, we haven't had much problems. Rgds, --- Peter ÅstrandThinLinc Chief Developer Cendio ABhttp://www.cendio.com Wallenbergs gata 4 583 30
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4689] trunk/common/fltk
On 10/4/11 4:34 AM, Peter Åstrand wrote: Frankly, the fact that the main project developers insist on the use of esoteric build environments is a problem. MinGW had 1,059,337 downloads the last 7 days. The method of cross compiling Windows binaries on Linux, using MinGW, is used by popular projects such as VLC. I'm not sure if you know about it, but VLC is a long-time open-source favorite, typically considered one of the best media players, and have had 36,900,001 downloads on cnet.com alone. Calling MinGW esoteric is just plain wrong. You are mixing your metaphors, Peter. Most people who use MinGW use it on an actual Windows machine, which is different from using it on a Linux machine. We already encountered one problem caused by this difference-- the fact that autotools on Windows was unusably slow and, prior to implementing a CMake-based build system for Windows, there was no reasonable way to build our code on an actual Windows machine. I'm not asking you to change the way you build things. If you want to use MinGW, then that's fine. If we didn't need Visual Studio for certain functionality, I'd be fine with not supporting it at all for this project, but as long as it's needed to get full functionality, then the primary project developers need to at least sanity check it. This most recent breakage went weeks before I was able to get around to building on Windows and discovering the issue, then I wasted an hour figuring out what was wrong. I'm not asking you to do anything that I don't also do myself. Further, aren't you also cross-compiling Mac code? though, we're all in the dark regarding what Cendio is doing with the code. It would be helpful to at least have some communication regarding upcoming ThinLinc releases, so we know generally what snapshot of the code that Cendio is testing/stabilizing. We are always using the trunk version. I figured that, but no one knows when you put out a release or what testing/stabilization is occurring on your end. Thus, we end up with dangling releases in the project, because Cendio's releases are not coincident with project releases, and you guys tend to lose interest in fixing things that aren't part of your release. Hence the situation with 1.1. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Drop old viewers?
Personally, I'd be in favor of removing the old viewers from trunk immediately. It doesn't make sense to me to keep code in trunk that isn't going to be part of a future release. trunk is not meant to be a stable code base. It's meant to be a next-generation code base on which new releases will be based. If we don't intend to make the old viewer a part of a future release, then it needs to be removed from trunk. If people are still using the old viewer, then that's what the 1.1 branch is for. On a side note, it also goes against every fiber of my being to ignore any bugs, and I sincerely hope we will not decide to ignore the bugs in the next release the way we have ignored them in the last release. It's hard for people to trust the stability of our next-generation code when the code that we're calling stable (1.1.0) has a bunch of bugs, by our own admission, and when we're deciding to abandon the stable branch. That isn't the way healthy open source projects behave. On 9/30/11 7:32 AM, Pierre Ossman wrote: There's a bunch of bugs in the tracker for the old viewers. Should we pay attention to those or should we start pointing people towards the new viewer? If the latter, then I guess we should also consider removing the old ones from trunk. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Moving to the wiki
On 9/23/11 6:17 AM, Pierre Ossman wrote: In order to make it easier to update information about TigerVNC, I suggest we move our web page over to the wiki. I've done an initial attempt at converting our existing page over. So if people could have a look, and if it looks okay then one of the admins could switch over to have it as our primary web page. Done. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4675] trunk/common/fltk
Never mind. I finally found the items (FLTK's bug tracker is a little
tricky to navigate.)
http://www.fltk.org/str.php?L2660+P0+S-2+C0+I0+E0+Q2660
http://www.fltk.org/str.php?L2636+P0+S-2+C0+I0+E0+Q2636
http://www.fltk.org/str.php?L2599+P0+S-2+C0+I0+E0+Q2599
http://www.fltk.org/str.php?L2641+P0+S-2+C0+I0+E0+Q2641
On 9/18/11 4:16 PM, DRC wrote:
Please post information regarding issues fixed by this patch.
On 9/16/11 6:51 AM, hea...@users.sourceforge.net wrote:
Revision: 4675
http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4675view=rev
Author: hean01
Date: 2011-09-16 11:51:32 + (Fri, 16 Sep 2011)
Log Message:
---
Updated bundled fltk with latest set of patches for
following fltk str: 2660, 2636, 2599, 2641...
Modified Paths:
--
trunk/common/fltk/FL/Fl_Widget.H
trunk/common/fltk/FL/mac.H
trunk/common/fltk/FL/win32.H
trunk/common/fltk/src/Fl.cxx
trunk/common/fltk/src/Fl_cocoa.mm
trunk/common/fltk/src/Fl_win32.cxx
trunk/common/fltk/src/fl_draw_pixmap.cxx
trunk/common/fltk/src/screen_xywh.cxx
Modified: trunk/common/fltk/FL/Fl_Widget.H
===
--- trunk/common/fltk/FL/Fl_Widget.H 2011-09-14 20:18:23 UTC (rev 4674)
+++ trunk/common/fltk/FL/Fl_Widget.H 2011-09-16 11:51:32 UTC (rev 4675)
@@ -108,7 +108,6 @@
*/
class FL_EXPORT Fl_Widget {
friend class Fl_Group;
- friend class Fl_X;
Fl_Group* parent_;
Fl_Callback* callback_;
Modified: trunk/common/fltk/FL/mac.H
===
--- trunk/common/fltk/FL/mac.H 2011-09-14 20:18:23 UTC (rev 4674)
+++ trunk/common/fltk/FL/mac.H 2011-09-16 11:51:32 UTC (rev 4675)
@@ -213,6 +213,9 @@
public:
/** Localizable text for the About xxx application menu item */
static const char *about;
+ /** Copyright notice for the default about dialog. Will use the
information
+ from the bundle if set to an empty string. */
+ static const char *copyright;
/** Localizable text for the Print Front Window application menu item.
This menu item won't be displayed if Fl_Mac_App_Menu::print
is set to an empty string.
Modified: trunk/common/fltk/FL/win32.H
===
--- trunk/common/fltk/FL/win32.H 2011-09-14 20:18:23 UTC (rev 4674)
+++ trunk/common/fltk/FL/win32.H 2011-09-16 11:51:32 UTC (rev 4675)
@@ -82,6 +82,7 @@
int wait_for_expose;
HDC private_dc; // used for OpenGL
HCURSOR cursor;
+ int custom_cursor;
HDC saved_hdc; // saves the handle of the DC currently loaded
// static variables, static functions and member functions
static Fl_X* first;
Modified: trunk/common/fltk/src/Fl.cxx
===
--- trunk/common/fltk/src/Fl.cxx 2011-09-14 20:18:23 UTC (rev 4674)
+++ trunk/common/fltk/src/Fl.cxx 2011-09-16 11:51:32 UTC (rev 4675)
@@ -86,6 +86,7 @@
//
#if defined(__APPLE__) || defined(FL_DOXYGEN)
const char *Fl_Mac_App_Menu::about = About ;
+const char *Fl_Mac_App_Menu::copyright = NULL;
const char *Fl_Mac_App_Menu::print = Print Front Window;
const char *Fl_Mac_App_Menu::services = Services;
const char *Fl_Mac_App_Menu::hide = Hide ;
Modified: trunk/common/fltk/src/Fl_cocoa.mm
===
--- trunk/common/fltk/src/Fl_cocoa.mm2011-09-14 20:18:23 UTC (rev
4674)
+++ trunk/common/fltk/src/Fl_cocoa.mm2011-09-16 11:51:32 UTC (rev
4675)
@@ -1666,6 +1666,7 @@
- (void)rightMouseDragged:(NSEvent *)theEvent;
- (void)otherMouseDragged:(NSEvent *)theEvent;
- (void)scrollWheel:(NSEvent *)theEvent;
++ (NSString *)keyTranslate:(UInt16)keyCode
withModifierFlags:(UInt32)modifierFlags;
- (BOOL)handleKeyDown:(NSEvent *)theEvent;
- (void)keyDown:(NSEvent *)theEvent;
- (void)keyUp:(NSEvent *)theEvent;
@@ -1754,6 +1755,130 @@
- (void)scrollWheel:(NSEvent *)theEvent {
cocoaMouseWheelHandler(theEvent);
}
++ (NSString *)keyTranslate:(UInt16)keyCode
withModifierFlags:(UInt32)modifierFlags {
+ const UCKeyboardLayout *layout;
+ OSStatus err;
+
+ layout = NULL;
+
+#if (MAC_OS_X_VERSION_MIN_REQUIRED = MAC_OS_X_VERSION_10_5)
+ TISInputSourceRef keyboard;
+ CFDataRef uchr;
+
+ keyboard = TISCopyCurrentKeyboardInputSource();
+ uchr = (CFDataRef)TISGetInputSourceProperty(keyboard,
+
kTISPropertyUnicodeKeyLayoutData);
+ if (uchr == NULL)
+return nil;
+
+ layout = (const UCKeyboardLayout*)CFDataGetBytePtr(uchr);
+#else
+ KeyboardLayoutRef old_layout;
+ int kind;
+
+ err = KLGetCurrentKeyboardLayout(old_layout);
+ if (err != noErr)
+return nil;
+
+ err = KLGetKeyboardLayoutProperty(old_layout, kKLKind,
+(const void**)kind);
+ if (err
Re: [Tigervnc-devel] [PATCH] Linking error on newer Linux distros
On 9/14/11 9:45 AM, Adam Tkac wrote: Hello all, I tried to compile new viewer (from trunk) and use bundled fltk but I got following error: /usr/bin/ld: ../common/fltk/src/libfltk_static.a(Fl_Preferences.cxx.o): undefined reference to symbol 'dlopen@@GLIBC_2.2.5' /usr/bin/ld: note: 'dlopen@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line /lib64/libdl.so.2: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [vncviewer/vncviewer] Error 1 make[1]: *** [vncviewer/CMakeFiles/vncviewer.dir/all] Error 2 make: *** [all] Error 2 Linker in new distributions doesn't allow indirect linking i.e. if some symbol, dlopen in this case, is needed by binary then library which contains the symbol must be passed as -llibrary linker argument. Attached patch just adds the -ldl, I don't think we need extra checking for it in CMakeLists because it is core part of all systems, do we? Let me see if I can perhaps remove the dependency, but otherwise, I agree that we don't need to check for it. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] [Tigervnc-commits] SF.net SVN: tigervnc:[4669] trunk/common/rfb
On 9/9/11 3:28 AM, Pierre Ossman wrote: Chill. Saying that people cannot do any changes without first getting your seal of approval and/or spending hours of testing even for small changes is not a constructive way to encourage development on this project. With respect to the Tight encoder, I am not trying to encourage development. It's a somewhat fragile piece of code that took a lot of time and domain expertise to get right. I don't want to change it unless there is a good reason to, such as a build problem or a new feature addition. The reason those variables are now dynamic is to avoid having to include jpeglib.h in any other place than JpegCompressor.cxx. We cannot have undefined structures as part of the class definition in that case, but pointers to undefined structures is okay. The reason we want to avoid jpeglib.h as much as possible is for things like this: typedef long INT32; typedef int boolean; Such generic typedefs have a very high probability of causing conflicts, and they do in practice with mingw. Including such information in the commit message or sending a quick note to the list following the commit would head off a lot of this misunderstanding. I accept your reasoning, but I now need to stare at the code for a bit to make sure there are no side effects to using dynamic allocation. -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
