The reality is that a lot of my users still want to build on RHEL 3.
Some of them even want to build on older Solaris versions for which
autoconf isn't even available. I disagree that we can ask more of them
than current VNC systems ask.
Users are not always developers. So in this case the ma
Also, a couple of questions regarding this list:
(1) I tried to join it a couple of weeks ago, but it never sent me a
confirmation, and now it appears that all of my messages are being held
for moderator approval.
I don't know why a confirmation was never sent; might have been a
temporary Sou
On Wed, 11 Mar 2009, Constantin Kaplinsky wrote:
This is exactly why I hate autoconf/automake and will not use them in
my own projects.
Is there any good substitution for autoconf/automake available?
There's the http://www.cmake.org/ project, which is used by KDE and
others. I haven't tried
On Wed, Mar 11, 2009 at 01:05:33AM -0500, DRC wrote:
> I am a GNU Make hacker, so I personally use raw GNU Makefile semantics
> for VirtualGL and other projects I do, but I am a bit of a nut in that
> regard. :) In terms of automated Makefile generators, CMake is a much
> more elegant solution th
On Wed, 11 Mar 2009, Adam Tkac wrote:
However, I'm not proposing for TigerVNC to do either of the above. I
just want to use a version of automake/autoconf that is more compatible
with Enterprise Linux platforms. My users are mostly standardized on
...
Support for old autotools is drawback. I
On Tue, Mar 10, 2009 at 05:19:05PM -0500, DRC wrote:
> OK, so I'm finally able to do an autoreconf with autoconf 2.61 and get
> reasonable configure scripts. However, I can't figure out how to build
> JPEG/SIMD. The README file says I should be able to do
>
> cd unix
> ./configure --with-tight-j
On Wed, Mar 11, 2009 at 09:03:20AM +0100, Peter Åstrand wrote:
> On Wed, 11 Mar 2009, Adam Tkac wrote:
>
>>> However, I'm not proposing for TigerVNC to do either of the above. I
>>> just want to use a version of automake/autoconf that is more compatible
>>> with Enterprise Linux platforms. My use
Adam Tkac wrote:
> parameter is called --with-included-jpeg ;)
>
The README file says:
If you want use zlib and jpeg distributed with TigerVNC you have to
run configure "./configure --with-tight-zlib --with-tight-jpeg".
so I guess it's a README bug.
> Please attach config.log from common/jpeg
On Wed, 11 Mar 2009 03:46:08 -0500
DRC wrote:
> Adam Tkac wrote:
> > parameter is called --with-included-jpeg ;)
> >
> The README file says:
>
> If you want use zlib and jpeg distributed with TigerVNC you have to
> run configure "./configure --with-tight-zlib --with-tight-jpeg".
>
> so I gue
On Wed, 11 Mar 2009 11:46:56 +0600
Constantin Kaplinsky wrote:
> Hello all,
>
> > Adam Tkac wrote:
>
> > as you can see I've changed version numbers to 0.0.90 and I think it's
> > time to decide what we want in the first release (1.0.0).
> >
> > [...]
> > - remove all TightVNC related stuf
On Wed, 11 Mar 2009 08:39:58 +0100 (CET)
Peter Åstrand wrote:
> We don't know if RealVNC are checking in their "configure" file in their
> source repository - we don't know if they are using version control
> software at all... Their releases certainly contains a 'configure' script
> though, t
On Wed, 11 Mar 2009 08:48:14 +0100 (CET)
Peter Åstrand wrote:
> > (2) Can we re-configure it such that replies go to the list? It is a
> > pain to modify the To: field each time I reply.
>
> You want a:
>
> Reply-To: tigervnc-...
>
> ? That's ok with me, but I know that some people hates it.
The current encoding autoselection is not working very well, and is
fundamentally wrong as it is implemented in the client (which has no
knowledge of the data and what encoding will be the most efficient).
Fixing this properly is a big task, so it's not something we
realistically can do for 1.0.0.
On Wed, Mar 11, 2009 at 01:40:29PM +0100, Pierre Ossman wrote:
> The current encoding autoselection is not working very well, and is
> fundamentally wrong as it is implemented in the client (which has no
> knowledge of the data and what encoding will be the most efficient).
>
> Fixing this properl
On Wed, 11 Mar 2009, Adam Tkac wrote:
We should always send "second preferred" encoding to server in case
that server doesn't support JPEG. So, in theory, existing code will be
improved this way:
for speeds >= 16Mbps client sends "Raw, JPEG, hextile, zrle"
for speeds < 16Mbps client sends "JPEG
On Wed, 11 Mar 2009 15:35:29 +0100
Adam Tkac wrote:
>
> If non-SIMD JPEG is not so slower than raw encoding we can prefer
> Tight JPEG encoding all the time. Otherwise we can use JPEG on low and
> medium bandwidth nets and raw on high bandwidth nets. I think that
> current algorithm which is cur
On Wed, Mar 11, 2009 at 03:55:11PM +0100, Pierre Ossman wrote:
> On Wed, 11 Mar 2009 15:35:29 +0100
> Adam Tkac wrote:
>
> >
> > If non-SIMD JPEG is not so slower than raw encoding we can prefer
> > Tight JPEG encoding all the time. Otherwise we can use JPEG on low and
> > medium bandwidth nets
I hate not having the feature enabled as much as you hate having it
enabled. I don't know how to make both of us happy.
To me, the potential downside of missing some critical conversation
(which often happens when people reply to someone and forget to make the
reply go to the list) far exceeds th
Raw by itself is completely useless. However, using a combination of
Raw tiles and paletted tiles, both encoded using the Tight encoder, is
useful. TurboVNC 0.5 does that for its mathematically lossless modes.
What we found is that there is really no reason to use any encoder other
than the Tigh
I did a study a while back which compressed every 10th frame of the
entire run of Viewperf using the entire range of JPEG quality and
subsampling settings and computed an average compression ratio from
these hundreds of images for each quality level (spreadsheet available
on request.)
Based on tha
20 matches
Mail list logo
