On 6/26/14 2:54 PM, Pierre Ossman wrote:
> Sourceforge mailing list management is horrible. It's only made
> tolerable by having other sites handle the archive. Google on the other
> hand has a very beautiful integration of web and email. So moving there
> is a massive plus in my book.
>
> As for o
Why can't you just keep the SF page for hosting releases and mailing lists and
other things that GitHub doesn't do or doesn't do well? Plenty of projects use
SF with an external source repository. I mean, your primary motivation for
moving to GitHub was, if I understand correctly, to make it eas
e 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 managemen
On 6/23/14 3:26 PM, Pierre Ossman wrote:
> I'm migrating the history since all the way from the start. But there
> are a whole bunch of side branches in our svn repo that has nothing to
> do with our current code base. It's for other versions of TightVNC.
> Keeping those around is just needless noi
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 rep
On 5/21/14 7:32 AM, Pierre Ossman wrote:
> My biggest current gripe is that it's annoyingly slow far too often.
> But the move is not just about avoiding the bad, it's a lot about
> getting improvements. Github's (and to a large extent git's) way of
> working is a lot more friendly to casual contri
Not that I care tremendously deeply about it, since I'm no longer an active
developer, but given that I actively maintain three projects on SF, I'm curious
to hear what doesn't work well with it, from your POV. Works fine for me,
although the ads are annoying.
> On May 21, 2014, at 4:14 AM, Pie
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 gat
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 compres
-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.
Ignore previous message. I spoke too soon. I will send a complete
analysis shortly.
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,
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
>>
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 thr
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,
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 understandin
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
On 12/19/13 5:10 AM, Pierre Ossman wrote:
> It is probably also interesting to see what limitations hardware
> decoders put on things. A mobile client with constrained CPU/power
> might benefit from H.264 simply because of the offloading.
Doubtful. If the performance is bandwidth-limited, then th
On 12/19/13 2:38 AM, Pierre Ossman wrote:
>> 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.
>>
>
> I even think there were two of them. I sent out some emails to t
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 wrote:
>
> Just wanted to give everyone a heads up on what I'm planning f
that I can think of is that the binary client probably
> has better support for multi-head setups. That could be remedied
> however, DRC has done it for the TurboVNC java viewer which shares a
> similar code base.
One of the other major differences in Java vs. C++ is performance.
/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
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
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
CC'ing the TigerVNC lists, since this may also interest some of those
users/developers.
I believe that the latest pre-release of VirtualGL
(http://virtualgl.sourceforge.net/vgl.nightly/) should (with emphasis on
"should") allow you to run compiz or other 3D WM's with hardware
acceleration. Cu
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 wrote:
> I haven't test 10.8 yet but it is working on 10.
On 6/10/13 4:18 AM, Pierre Ossman wrote:
> I tested on the 10.8 and 10.4 machines we have here for testing
> ThinLinc, and the results were:
>
> 10.8: Works fine (AFAICT)
>
> 10.4: Boom:
>
> lab-21:~/Desktop aaron$ ./TigerVNC\ Viewer\
> 1.2.90.app/Contents/MacOS/TigerVNC\ Viewer
> dyld: Symbo
Not sure which version of Xcode you're using, but the last one that
contained the 10.6 SDK was 4.4.x. If you're normally using a newer
version of Xcode, then you can install the old version under a different
name (for instance, /Applications/Xcode4.4.x.app.) Then, making the
build backward co
Works for me.
On 5/18/13 5:29 PM, Brian Hinz wrote:
> On Fri, May 17, 2013 at 2:30 PM, DRC <mailto:dcomman...@users.sourceforge.net>> wrote:
>
> Brian,
>
> While we're on the subject, the Mac build has similar issues. It won't
> run on Mountain L
n Hinz wrote:
>> On Fri, May 17, 2013 at 2:06 PM, DRC
>> wrote:
>>> 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 depe
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. Jus
ATIC macro that exists in the TigerVNC source.
On 5/17/13 1:06 PM, DRC wrote:
> 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
>
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
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=5092&view=rev
>
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
The pre-releases I used to provide were "cross-compatible" builds designed to
work on a variety of Linux platforms. They were built that way because we were
considering at the time merging TurboVNC with TigerVNC, and one requirement of
that was having a single binary that any Linux user could in
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
Date: Tue, 26 Feb 2013 03:37:12 -0600
Subject: [PATCH 1/4] Add BUIL
e time to do another release of TigerVNC. One issue I'd
>>> like to revisit for that release is that of an upgrade to GPLv3.
>>>
>>> Last time we had this discussion, Cendio was for it and so was Adam.
>>> DRC was opposed to it though. Since then DRC has mov
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
like to revisit for that release is that of an upgrade to GPLv3.
>
> Last time we had this discussion, Cendio was for it and so was Adam.
> DRC was opposed to it though. Since then DRC has moved away from
> TigerVNC, and we've gotten Brian Hinz as a major contributor of Java
>
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
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=5031&view=rev
> Author: astrand
> Date: 2013-01-22 08:11:05 + (Tue, 22 Jan 2013)
> Log Messag
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 w
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
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
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 ma
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://tig
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 th
These are issues I encountered when attempting to build Linux, OS X, and
Windows builds from the code in trunk:
(1) BUILDING.txt needs to be modified to indicate that
fltk-xfixes-xcursor-cmake.2.patch should be applied with patch -p0, not -p1.
(2) It would be much more convenient if BUILDING.
Why would vncpasswd need to accept an encrypted password? vncpasswd's
only purpose is to encrypt a plain text password and write it to a file.
If you already have an encrypted password, just write it directly to
the VNC password file instead.
VNC uses DES3 to encrypt passwords for VNC Passwo
client on each machine (or multiboot OS) I work with. A
> quick check shows that it supports local and remote SVN repositories.
>
> Robert
>
>
> On 11/27/2012 02:26 PM, DRC wrote:
>> On a side note, if anyone knows of a Subversion "thick client" that has
>>
ventually.
>
> 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:
>>
rand 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
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 opti
I suppose this has been pocket vetoed.
On 10/2/12 9:56 AM, DRC wrote:
> 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
>>&
On 10/2/12 5:24 AM, Pierre Ossman wrote:
> It would seem so, yes. x0vncserver is mostly a proof-of-concept than a
> production ready implementation. Nobody's really working on it.
>
> As an alternative, TigerVNC has a Xorg VNC module that you can load
> into your normal X server. This will give you
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 attemp
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
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
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 con
On 9/5/12 11:24 PM, Brian Hinz wrote:
> Is there any good reason why the "rh692048" patch [1] that RedHat,
> Debain, etc. are applying hasn't been merged into the trunk? I see
> Martin's point regarding the order of the security types in this thread:
>
> http://www.mail-archive.com/tigervnc-devel@
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
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 seemi
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
expre
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
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 swin
>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 probabl
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 a
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
(N
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 bu
d 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 w
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 allowi
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
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);
> + los
On Tue, 28 Feb 2012 17:23:01 -0600
>> DRC wrote:
>>
>>> Seems like it might be intended to be linked with Xft instead, but I'm
>>> not sure why it is failing only on your platform (I've never seen this
>>> issue, and presumably no one else has
Seems like it might be intended to be linked with Xft instead, but I'm
not sure why it is failing only on your platform (I've never seen this
issue, and presumably no one else has either before now.)
On 2/28/12 10:34 AM, Paulo Edgar Castro wrote:
> Hi there.
>
> I was asked in the channel to rai
e.
> 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"
&
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
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=4857&view=rev
> Author: bphinz
> Date: 2012-
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
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 th
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 th
On 2/9/12 6:34 AM, Pierre Ossman wrote:
> On Sun, 05 Feb 2012 15:32:52 -0600
> DRC 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
e.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 -060
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.
On 2/3/12 9:00 AM, Pierre Ossman wrote:
> On Tue, 31 Jan 2012 05:03:06 -0600
> DRC wrote:
>
&g
o the Java client, we are currently not using that one,
> so I have no strong opinion.
>
> Rgds,
> Peter
>
> On Thu, 2 Feb 2012, DRC wrote:
>
>> I hadn't actually branched 1.2 yet, so trunk is still supposed to be
>> stable. I was waiting for a more reas
t; 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
>
>
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
> htt
On 1/31/12 2:57 AM, Pierre Ossman wrote:
> On Mon, 30 Jan 2012 15:55:11 -0600
> DRC 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 d
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: 48
On 1/23/12 3:16 PM, Pierre Ossman wrote:
>> I disagree with this patch. As we discussed and agreed to in the bug
>> report, we cannot support arbitrary configurations in which a user tries
>> to set up their own version of FLTK with limited functionality. Either
>> it has the necessary functional
I disagree with this patch. As we discussed and agreed to in the bug
report, we cannot support arbitrary configurations in which a user tries
to set up their own version of FLTK with limited functionality. Either
it has the necessary functionality for TigerVNC or it doesn't.
If this patch is tru
On Dec 28, 2011, at 10:22 AM, Peter Åstrand 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
> op
On Dec 28, 2011, at 9:25 AM, Peter Åstrand 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 specia
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
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
On 12/22/11 3:50 AM, Pierre Ossman wrote:
> Testing and preparing for release here has meant that I haven't had
> time to look at this properly yet. My current attitude towards it right
> now though is that, yes, a regression of the magnitude you're seeing is
> not desired and should be fixed. I wo
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 squash
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.co
M, Pierre Ossman wrote:
> On Wed, 07 Dec 2011 04:39:40 -0600
> DRC wrote:
>
>>
>> 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 som
11 2:45 AM, Pierre Ossman wrote:
> Any luck getting this working?
>
> On Thu, 1 Dec 2011 11:31:25 +0100
> Pierre Ossman wrote:
>
>> On Wed, 30 Nov 2011 15:47:14 -0600
>> DRC wrote:
>>
>>>
>>> Yes, I'm getting the "enabling continuous u
1 - 100 of 618 matches
Mail list logo
