On 3/24/13 7:20 PM, First Last wrote:
I was busy last days... anyway I got turbovnc from AUR repo (archlinux)
now everything works fine. But I think there is a problem with make
install from the sources codes, because it's not normal that vncserver
wasn't where I expect, and I didn't mess with
is now available at:
https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.1.95%20%281.2rc%29/
There were enough issues discovered with the Java viewer that I felt it
prudent to give the community another pass at testing it before the
final release is issued. All remaining issues that
No, VirtualGL does everything through the X server. This sounds like more of a
driver thing. Not sure what it would speed up in our case. Pixel readback is
already hundreds or even 1000+ Megapixels/sec on modern hardware. That's not
even close to being a bottleneck when compared to compression
Well, I actually tried to get xpra up and running. No luck. It seems
to be a somewhat unpolished solution. The X proxy we support is
TurboVNC, so I would suggest that as an alternative.
On 4/20/13 9:32 PM, Yusen Li wrote:
I use Xpra to run applications remotely and it works fine for 2D
On 4/24/13 9:16 PM, Yusen Li wrote:
encoding is excellent for video games and the Turbor VNC or TigerVNC is
not good at games. I also suggested TigerVNC group to add the video
encoding techniques (such as x264) to TigerVNC. But they told me they
don't want to do that since the encoding is just
it in a multi-card
environment, so others on the list may be able to provide a better answer.
DRC
On 4/26/13 2:28 PM, Kevin Van Workum wrote:
I know how to setup two graphics cards with a single x-server with two
screens (one screen for each card) and address them via VGL_DISPLAY. But
I'm
On many platforms, the 32-bit compiler infrastructure is in a set of
extra packages that aren't installed by default. Make sure that you can
successfully compile a 32-bit app using -m32 (Hello, world or
whatever.) The VirtualGL build system enables either 32-bit or 64-bit
based on the value
On 5/7/13 5:57 PM, Damon Catling wrote:
I have no idea weather Nvidia and Valve already have their own remote 3D
solutions for Linux similar to VirtualGL, but if not, perhaps VirtualGL
would be attractive to companies of that ilk?
Valve, possibly. nVidia has their own solution called VGX,
On 5/7/13 2:32 PM, Kevin Van Workum wrote:
When running the java viewer in listen mode with loglevel=100, if the
vncserver is killed, an exception is thrown in the java viewer. The
viewer window also remains open. Not really a bug though but would be
nice if the viewer window would close on
Please submit all bug reports to me no later than Wednesday 5/15 (or
remind me if I haven't fixed something yet.)
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to
There was an issue that was making the TurboVNC server crash on startup
when using recent systems, such as Fedora 18 or Ubuntu 13.04. You might
be running into that same issue. Can you try building the code from
https://virtualgl.svn.sourceforge.net/svnroot/virtualgl/vnc/branches/1.3.x
in
to
determine success of the connection on the server side. Maybe you could
keep the asynchronous behavior default and just add a -sync option to
request a synchronous connect instead? Either way.
On Fri, May 10, 2013 at 4:05 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman
On 5/12/13 11:31 PM, First Last wrote:
you mean 1.2.x right ? because I can't get 1.3.x
anyway, I compiled (after a change in FindTurboJPEG.cmake) the server
and the client I got (1.2.x).
Yes, sorry. I meant 1.2.x. Too many releases going on at once
(libjpeg-turbo is about to be released as
On 5/13/13 8:41 AM, First Last wrote:
actualy it's what I did, make xserver-install ( when I wrote the mail
I was almost asleep...) so to be clear make xserver-install didn't
install vncpasswd.
'make install' installs vncpasswd and vncconnect. 'make
xserver-install' installs Xvnc. You have
On 5/13/13 12:57 PM, First Last wrote:
well, if you want, I can make a partition with archlinux and giving to
you an ssh access sometime. I could either do some tests for you and
send logs. I cannot be too much involved, I cannot code or debuging
because I try to be hired by a gsoc project.
Thanks. I'll get this integrated into 1.2.
On 5/21/13 7:56 AM, Kevin Van Workum wrote:
Specifying a desktopName in a config file (turbovncserver.conf) has no
effect.
Simple fix:
*** vncserver.in http://vncserver.in2013-05-14
09:58:51.641671306 -0400
--- vncserver.in.b
On 5/30/13 2:49 PM, Jay Ashworth wrote:
When I upgraded them to SuSE 12.1, the replacement Xvnc from the new Tight
package wouldn't accept mouseclicks, so I again copied in the older one,
and *it*, in its turn, wouldn't allow drag and drop, though everything
else seemed to work ok. They lived
solves a problem
that couldn't be solved by using VGL_FPS with frame spoiling disabled.
On Jun 2, 2013, at 3:58 PM, Dyweni - VirtualGL-Users t7nhgfds7...@dyweni.com
wrote:
Hi DRC/All,
I have mucked around with the VirtualGL 2.3.2 code and have come up with a
solution that seems to work well
patch for your review / feedback. Any feedback
would be great.
---
Thanks,
Dyweni
On 2013-06-02 23:36, DRC wrote:
But you didn't answer my question. Why can't you achieve the same
effect by setting VGL_FPS and disabling frame spoiling? The reason why
frame spoiling exists is to make 3D
Dyweni,
I await your response on this before I proceed any further. I need to
resolve the matter of whether you simply forgot to disable frame
spoiling (which is what I suspect, since your previous messages made no
mention of using the -sp switch to vglrun or setting VGL_SPOIL to 0) or
quite plainly multiple times that it would?
I have another patch coming soon that implements GLX_SGI_swap_control /
glXSwapIntervalSGI and perfects the delay within glXSwapBuffers.
---
Thanks,
Dyweni
On 2013-06-04 14:13, DRC wrote:
Dyweni,
I await your response on this before I proceed
vnc server and that the -fps option
was already addressing the over-the-wire lag issue.
---
Thanks,
Dyweni
On 2013-06-04 17:27, DRC wrote:
On 6/4/13 3:16 PM, Dyweni - VirtualGL-Users wrote:
You are correct. Running vglrun with '-sp -fps 60' limits the 3D
rendering rate as you described
On 6/4/13 8:51 PM, Nathan Kidd wrote:
Is there a reason for -fps to not automatically enable -sp?
I'm not thinking of any use case for -fps apart from -sp; as you've
said, in the typical use case of wanting to rate-limit your
app/bandwidth you always need -sp.
Not true. VGL_FPS was
(60) of the Emulated
Monitor Refresh Rate setting.
---
Thanks,
Dyweni
On 2013-06-04 15:16, Dyweni - VirtualGL-Users wrote:
Hi DRC,
You are correct. Running vglrun with '-sp -fps 60' limits the 3D
rendering rate as you described. The 3D rendering rate follows the -fps
value. I didn't
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.
Bigger pipes will definitely help, up to a point. The compression ratio
you can get will vary a lot depending on the types of images that the
app is generating. I use GLXspheres as a sort of middle-of-the-road
approximation, since it has a realistic proportion of solid color and
smooth
On 6/15/13 11:13 AM, Paul Melis wrote:
I've done some similar tests, mostly at 3840x2160 over a 10G link. I
seemed to hit a bottleneck of about 10 fps, but so far assumed it was
the readback from the GPU that was the problem (GTX680 in a PCI Express
x16 slot), judging from the vglrun +pr
in full
res, but only a portion, is the out of view portion not sent?
The point James just made is also something I need to try, I forgot to look
if the ssh daemon was maxing out! And I should test with it without any
tunnel at all.
Cheers,
Paul
- Original Message -
From: DRC
representative of how it might
act on a real display. It appears the answer is yes - so I'll test with that
and see what I can come up with.
I'll post some results.
Cheers,
Paul
- Original Message -
From: DRC dcomman...@users.sourceforge.net
To: virtualgl-users@lists.sourceforge.net
, 2013 at 12:50:01PM -0500, DRC wrote:
I dunno about that. My modest Quadro 600 can read back about a
gigapixel/second. I don't think that's likely to ever be the bottleneck
on a reasonably modern system.
I have seen some slides that suggest that nVidia cripples the readback
performance
glreadtest in the VirtualGL source.
On Jun 15, 2013, at 7:22 PM, Vadim Peretokin vpereto...@gmail.com wrote:
I have a GTX 560 that I could run a test on, if there are any easily
available and anyone wants to look at the number.
Does enabling PBOs make any difference?
On 6/17/13 2:02 AM, Arthur HUILLET wrote:
On Mon, Jun 17, 2013 at 11:30:34AM +1000, Paul McIntosh wrote:
Ok - here is the data for a Tesla M2070 and M2070Q (Quadro)
There is a big difference between the Quadro and non-Quadro. Looks like the
read rate
xwd also (more old school solution.) TurboVNC is an X server, so any tool that
can capture an X screenshot should work. You can also of course grab the image
on the client side using any number of different tools.
On Jun 28, 2013, at 2:40 PM, Kevin Van Workum v...@sabalcore.com wrote:
I was
The SecurityTypes option can only be used to control a VeNCrypt-compatible
server like TigerVNC. TurboVNC doesn't currently support session encryption, so
encryption=None will always be the case when connecting to TurboVNC servers.
You can use the auth config file to restrict the available auth
Should be fixed in trunk and branches/1.2.x. The viewer now disables
the keystroke buttons whenever view-only mode is selected on the viewer
side. If view-only mode is selected on the server side instead, then
the viewer won't know about it. In that case, the buttons will still be
visible,
I suspect that it may be the same bug as is reported here:
https://sourceforge.net/tracker/?func=detailaid=3606409group_id=117509atid=678327
Thanks to the sponsored project I've been working on in recent weeks to
make compiz run in VirtualGL, I now have a recent-ish Ubuntu environment
set up
package builder but with the nightly sources.
Cheers
On Sat, Jul 20, 2013 at 2:16 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
I don't think their nightly is pulling the latest code from SVN, so
it probably doesn't contain the fixes. I know
the response =]
Thanks,
John
On Sat, Jul 20, 2013 at 2:16 AM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
I suspect that it may be the same bug as is reported here:
https://sourceforge.net/tracker/?func=detailaid=3606409group_id=117509atid
I can personally attest that TurboVNC does work on ARM Linux, both
client and server, but you have to build it (and libjpeg-turbo) from
source. I have tested TurboVNC on a Panda board with Ubuntu, but if you
run into any problems, please file a bug report. My philosophy behind
supplying
Install the proprietary Catalyst (fglrx) drivers from ATI/AMD. We don't
currently support Mesa. There generally isn't much impetus to do so,
because if you're using software rendering, you might as well use Mesa
directly-- either through the built-in version that TigerVNC supplies
via its
=0x01c2 ) 0.483990 ms
[VGL] ) 1.422030 ms
gnome-session-is-accelerated: No GLX_EXT_texture_from_pixmap support.
[VGL] XCloseDisplay (dpy=0x09072348(:20) ) 0.294950 ms
gnome-session-check-accelerated: Helper exited with code 256
Thanks so much for your time.
On 8/17/2013 12:03 AM, DRC
.el6.x86_64 does not work ( vglrun /bin/ls
-l / hangs )
I have no other versions to try.
-hiroto
On Fri, Aug 16, 2013 at 11:28 PM, DRC dcomman...@users.sourceforge.net
wrote:
Disabling SELinux is definitely the first step, but in some cases, you
also have to do:
attr -S -g selinux /usr
On 8/22/13 10:04 AM, John Clyne wrote:
The Quadro 2000, and I think the 550, are based on the older Fermi
architecture. I wanted to get confirmation that ViritualGL was supporting the
newer Kepler based products. I would think Kepler-Quadro would be supported,
but the Tesla cards target
:
FYI
While waiting for confirmation, I tested another VNC client called
'bVNC Free - Secure VNC Viewer' and that works just fine! Looks like a
VNC Client issue to me.
---
Thanks,
Dyweni
On 2013-08-27 11:48, DRC wrote:
Yes.
On 8/27/13 11:08 AM, Dyweni - VirtualGL-Users wrote:
I have
No idea what's causing the beeps, but both the Java and Windows native
viewers have an option to disable transmission of them from server to
client. Look in the Options dialog.
On 8/27/13 3:07 PM, Dyweni - VirtualGL-Users wrote:
Hi,
Ever since I started running Eve Online/Wine inside of
I'm not sure I totally understand. If the TurboVNC server is issuing
the calls in the correct order, then how would changing something within
the TurboVNC server work around the issue? Can you be more specific
about what xdotool is doing? An output from xev would help.
On 9/3/13 12:38 PM,
Neat trick. :)
I don't think that the issue you're seeing has anything to do with VGL
per se. I think it's how your X server is configured. $gpu in your
examples below refers to an X screen number. Typically, in a VirtualGL
multi-GPU environment, one would configure the X server such that
I have heard from at least one person that it is possible, but I have
not personally tried it. I'm not sure why you bothered with all the
help wanted ads. All you had to do was e-mail me. I'm the guy who
founded the VirtualGL Project, has been solely maintaining it for 10
years, and has
Yeah, but a single high-end GPU is going to render OpenGL faster than
all of the 200-some-odd cores in your cluster combined. Seems like a
good trade-off to me.
On 9/19/13 1:27 PM, Amanda Tumminello wrote:
I am currently working in a blade server environment. It consists of 13
blades with
.
On Wed, Sep 18, 2013 at 10:52 PM, DRC
dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
Neat trick. :)
I don't think that the issue you're seeing has anything to do
with VGL
per se. I think it's how your X server
I've just put out a new pre-release of TurboVNC
(http://virtualgl.sourceforge.net/vnc.nightly.13) that gives a sneak
preview of one of the biggest changes in TurboVNC 1.3:
Retiring the X11 viewer
---
It has been decided to get rid of the X11 viewer, although it will still
:(1781,872),
mode NotifyUngrab, detail NotifyInferior, same_screen YES,
focus YES, state 0
2013/9/26 Rafael Guimaraes rgu...@gmail.com mailto:rgu...@gmail.com
Hi DRC,
I have just detected a strange behavior when using TurboVNC 1.2
client as an applet. When I hold two mouse
The default is for ALR to affect only PutImage operations, which is what VGL
uses to draw images. Many 2D apps use other methods to draw images, like X
Render or CopyArea, that won't be subject to ALR unless you set TVNC_ALRALL.
The docs go into more detail. ALR is really targeted at 3D apps.
. But then why do I get that 1 initial refresh?
On Fri, Oct 4, 2013 at 5:08 PM, DRC dcomman...@users.sourceforge.net wrote:
The default is for ALR to affect only PutImage operations, which is what VGL
uses to draw images. Many 2D apps use other methods to draw images, like X
Render or CopyArea
:55 PM, Nathan Kidd wrote:
On 10/07/2013 05:32 PM, DRC wrote:
On 10/7/13 3:56 PM, Karthikeyan Balu wrote:
I’m not sure whether their drivers support access from Virtual display
servers ? and I guess TurboVNC being able to simulate these inputs comes
next. Any experience.
3DConnexion
,
you'll have to build from source if you want to try it out.
On 10/4/13 4:24 PM, Kevin Van Workum wrote:
OK, that makes sense. But then why do I get that 1 initial refresh?
On Fri, Oct 4, 2013 at 5:08 PM, DRC dcomman...@users.sourceforge.net wrote:
The default is for ALR to affect only
Try something more simple first, like WGLspheres
(http://www.virtualgl.org/wglspheres.zip). WGLspheres will print out
the OpenGL renderer, which should say Chromium if the 3D Guest
Additions are working properly.
Unfortunately, it is entirely possible that WGLspheres will work fine
but the
I know that VirtualGL has worked successfully with other Java 3D apps in
the past, but I haven't tested it in a long time. I'll see if I can
bring up a more simple 3D Java app and verify if there is a fundamental
issue in Java.
In the meantime, you might also want to try 'vglrun -ge', which
https://sourceforge.net/projects/virtualgl/files/VirtualGL/2.3.3/
Significant changes since 2.3.2:
[1]
VirtualGL will no longer throw an exception if a 3D application calls
certain X11 and GLX functions with a NULL argument. It will instead
allow the underlying X11 or GLX library to handle
This has been reproduced. It seems that LWJGL requires either the RANDR
extension or XFree86-VidModeExtension to be present in the 2D X server,
or it will barf. Since I'm in the process of adding X RANDR support to
TurboVNC, that will be the long-term solution for this, but in the near
term,
I guess I should have really learned by now to stop second guessing
myself. Upon further examination, the reason why the firstUpdate
mechanism is there is because there may be circumstances under which a
user leaves their 3D application running and then reconnects to the
TurboVNC Server
that if this was a bug in TurboVNC, someone else would have stumbled
upon it by now.
On 10/24/13 9:26 AM, Rafael Guimaraes wrote:
Hi DRC,
Just some last information... I have tried to telnet Xvnc (in ports 5813
and 5913, since I using display 13) in order to see if the Xvnc process
is completely
also been fixed by the same
patch.
On 9/26/13 2:59 PM, Rafael Guimaraes wrote:
Hi DRC,
I have just detected a strange behavior when using TurboVNC 1.2 client
as an applet. When I hold two mouse buttons simultaneously it doesn't
work as expected...
By using xev, I have checked that if I press
with fglrx driver. tried it with 2 different
graphics cards (one using fglrx other fglrx-legacy) but none works. it
just bothers me i have no problems with other applications.
On 23/10/2013, DRC dcomman...@users.sourceforge.net wrote:
There is clearly something different about your system
I suspect that it's some GPU-specific issue, as it does not occur with
an nVidia card. I have not had a chance to test it with my ATI adapter.
Be patient.
On 10/30/13 9:35 PM, GOliath Keet wrote:
I have a ATI 7850 with ati's current stable driver on ubuntu 13, same
problem existed for 12,
The application still only uses the CPU.
Am I missing something?
Thanks for the help btw.
--
Desmond
On Wednesday, November 6, 2013 at 12:47 PM, DRC wrote:
Trouble initializing VirtualGL with Xvfb tells me nothing. Please be
specific as to the error messages you are encountering or what
?
I did not manage to get the gnome fallback working, I will try a bit
more to understand what is wrong.
Thanks,
Julien
On Mon, Nov 11, 2013 at 5:55 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
Unfortunately, in Ubuntu 12.10, they removed Unity
) but none works. it
just bothers me i have no problems with other applications.
On 23/10/2013, DRC dcomman...@users.sourceforge.net wrote:
There is clearly something different about your system, then, because I
can run that application just fine with TigerVNC+VirtualGL (and with the
version
All of this becomes immensely more complicated when you start to factor
in Wayland, since all of the current remote display solutions are based
around X, and unfortunately, the Wayland developers seem to be taking
the position that remote display will take care of itself and that it
isn't
You can thank the sponsor of the technology. Yes, I anticipate it being
stable for 1.3, but since I don't personally use the feature, I am
relying on feedback from people who do, including the sponsor.
On 11/16/13 10:17 PM, Dyweni - VirtualGL-Users wrote:
-- The Java applet can now be
a newer version of X RANDR. That's a pretty major undertaking.
Such a feature seems like it is less useful now that you can dynamically
resize the server's desktop to any arbitrary geometry.
On 2/27/13 6:26 AM, DRC wrote:
Ah, yes, sorry for the confusion. The feature I'm describing is called
https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.2.1/
Significant changes since 1.2:
[1] Fixed two regressions introduced in TurboVNC 1.0, one of which
prevented older (RFB = 3.3) VNC clients from connecting successfully to
the TurboVNC Server and the other of which prevented
Never mind. I read the bug report. Not sure why it's requiring GLX. As a
temporary workaround, you can enable Mesa in TightVNC using the instructions
here:
http://www.virtualgl.org/Documentation/Mesa
I will look into why Evolution isn't working in VGL, mainly because doing so
may reveal an
. Debian squeeze has gnome ver 2.30 wheezy gnome 3.4.
My workaround is that I don't use evolution now, but other email program
(kmail). I made this change a half year ago, but kmail still annoying me.
Mirek
On Friday, November 29, 2013 05:46:09 AM DRC wrote:
Never mind. I read the bug
/Documentation/Mesa
I substituted debian library with library compiled with x11 driver.
After this, evolution is doing similar like with VGL. It starts but crashes
after compose is selected.
Mirek
On Friday, November 29, 2013 05:50:19 PM DRC wrote:
TurboVNC works well with both 2D or 3D applications
VirtualGL only opens one connection to :0 (or the specified 3D X server)
the first time XOpenDisplay() is called, and it reuses that same
connection for all subsequent 3D operations. Thus, VirtualGL is only 1
client from the 3D X server's point of view. I think Xorg can have a
max. of 256.
So I guess the limit is in vglclient. However 17 should be more than
enough.
On Thu, Dec 5, 2013 at 5:28 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
VirtualGL only opens one connection to :0 (or the specified 3D X server)
the first time
By chance have you tried the latest code in subversion trunk? I think
this may be another symptom of a bug I already fixed, but it was fixed
after the 2.3.3 release.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
We have a VNC + VirtualGL setup on machines with dual AMD FirePro V9800 ATI
I've never seen that before. Seems like it may be a driver bug.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
PS: One other big of strangeness I noticed was that under the single card
configuration all the tc visuals from DISPLAY=:0 glxinfo have id 0x0a3
81 GLX Visuals
...
0x0a3 32 tc 0
machine, this
will have to wait a while, until I have some other reason to change the card.
On Dec 23, 2013, at 10:15 AM, Tyson Whitehead twhiteh...@gmail.com wrote:
On December 21, 2013 03:03:25 DRC wrote:
By chance have you tried the latest code in subversion trunk? I think
this may
the clarification, I’ll definitely spend more time in
the manual. This is really helpful, I’ll take another stab at it.
Thanks again!
--
Desmond
On Wednesday, November 6, 2013 at 2:56 PM, DRC wrote:
Yes, you're missing quite a lot. Please read the manual. VirtualGL
needs two X
, 2014 at 11:53 AM, Kevin Van Workum wrote:
DRC was correct. You need a 3D X server, which is your Xorg X11
server. And you need a 2D server; either VNC or Xvfb, not both. If you
goal is to use Xvfb to capture images, then use Xvfb as the 2D server.
On Fri, Jan 10, 2014 at 1:53 PM, Stealthy
On 1/10/14 2:38 PM, Kevin Van Workum wrote:
Can you explain why you're using Xvfb? If you're just trying to make a
video of your 3D application with ffmpeg, can't you just get it from the
3D X server directly? For example:
ffmpeg -f x11grab -video_size cif -framerate 25 -i :0.0 /tmp/out.mpg
What option did you select in vglserver_config? What was the full
output of vglserver_config? Which version of the nVidia drivers do you
have installed?
vglserver_config installs a file under /etc/modprobe.d that is supposed
to set the permissions on /dev/nvidia*. If you haven't restarted
rebuilding the code.
On 4/25/13 3:26 AM, Arthur Huillet wrote:
On Wed, 24 Apr 2013 16:08:45 -0500
DRC dcomman...@users.sourceforge.net wrote:
In my case, I built
xpra on RHEL 6 and got the following error when I tried to connect:
For what it's worth - there are RHEL 6 packages available
I'll give it a try and see if I can reproduce it. Although
compatibility problems are becoming more and more rare as VirtualGL
matures, they still exist. Usually it's because the application is
doing something that I haven't anticipated.
On 1/27/14 6:49 AM, Dr. Roman Grothausmann wrote:
On 1/30/14 5:36 AM, Dr. Roman Grothausmann wrote:
On 29/01/14 10:30, DRC wrote:
The bug is easily reproducible. I am suspicious that it might have
something to do with the application's use of FBO's, but I'm not
entirely sure what the problem could be, as other apps that render to
FBO's
Moved the discussion temporarily to the voreen forum. Will update this
list once a conclusion has been reached.
On 1/31/14 6:50 AM, Dr. Roman Grothausmann wrote:
On 31/01/14 04:02, DRC wrote:
On 1/30/14 5:36 AM, Dr. Roman Grothausmann wrote:
On 29/01/14 10:30, DRC wrote:
The bug is easily
the graphics of other 3D apps started with vglrun (e.g. itk-snap, even the
instances started by other users) are effected (e.g. artefacts in the
rendering,
bg-color taken from the voreen canvas).
Is that as expected or a bug in specific for voreen over virtualGL?
On 31/01/14 22:02, DRC wrote:
Moved
All of the packages I'm building for TurboVNC 1.3 (pre-release build) include
the libjpeg-turbo libraries along with the Java viewer, so they are used
automatically. Otherwise, with the 1.2 Java viewer, you have to just install
the appropriate libjpeg-turbo binary package for your platform, and
What version of HyperMesh? Altair actively sells VirtualGL and TurboVNC
as part of their grid service offering, so I know that it has been
tested. The only possibility is that a new version came out that broke
something, or perhaps there is something different about your environment.
What
on RHEL6 x86_64. I am
not at work right now so I can't check the exact version.
As it works (mostly) okay with VirtualGL 2.3 but not with VirtualGL
2.3.3 (nor with 2.3.2) it looks to me like a regression in recent
versions of VirtualGL.
2014-02-26 20:10, DRC skrev:
What version of HyperMesh
flickering when painting the
Hyperbeam window. Hypermesh 11.0 has no visual anomalies as far as I can
see.
2014-02-27 19:59, DRC skrev:
Altair is looking into it. Are the visual anomalies specific to a
particular viewer? Do you, for instance, see them with both the Java
and the native viewer
turbovnc viewer. I read hypermesh viewer...
We are not using turbovnc. We use Cendio's thinlinc (version 4.0). Their
tigervnc Xvnc support softare glx so if I run hypermesh without vglrun
it works okay albeit slower.
2014-02-28 09:41, DRC skrev:
You mean the native Windows viewer? Which
I will investigate
On 3/11/14 6:34 AM, Isamu Yamashita wrote:
Hi folks,
When I used newer turbovnc with the option -query to enable XDMCP, I got
the following errors and Xvnc did not work normally. This issue happened
in both
1.2.1 and 1.2.80. I have used 1.1 with XDMCP so far and have
It's also perfectly fair to file a support request with nVidia for this.
I've encountered user reports that 32-bit apps are slow in VGL but
64-bit apps aren't, but in all cases it turned out to be because the
user hadn't installed the 32-bit libraries for the nVidia drivers.
However, in this
still using
remote stereo with it, please let me know. I welcome any feedback on
this proposal.
DRC
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases
On 3/24/14 11:01 AM, Nathan Kidd wrote:
As an OpenText developer dealing with 3D, I never hear of anybody using
VirtualGL + Exceed 14 on Windows.
In the same way that you focus on VirtualGL + TurobVNC we focus on
VirtualGL + Exceed VA TurboX (formerly Exceed onDemand) because users
will get
On 3/24/14 9:00 AM, Kevin Van Workum wrote:
Confused about the lion's share of VirtualGL users are no longer using
vglclient. Does that apply to Cygwin/X only or all platforms? I hope
you're not thinking of getting rid of vglclient.
It was a clear statement. Few people are using vglclient.
Sorry for the delay on this. Both issues have been reproduced, and I'm
investigating.
On 3/3/14 1:25 AM, Patrik Pira wrote:
Yes, flickering does occur with VGL 2.3. It does go away when I switch
to software opengl.
2014-02-28 18:39, DRC skrev:
OK, fair enough. I'm working with Altair
201 - 300 of 385 matches
Mail list logo
