Switches for RENDER extension?

[sigwx314]

Hi

I'm running a commercial software package on CentOS7, that is completely fine with the old TigerVNC that comes installed, but when I use TurboVnc (built from the dev branch in the git repo), the software issues a warning that the RENDER extension wasn't found.  Things work ok, but I'd like to clear the warning if I can.  Odd thing is that 'xdpyinfo' shows RENDER in the extension list on the TurboVnc server, so I'm not sure what else could be missing.   Other than the switches to enable/reference the local libturbojpeg, I have not enabled any special build switches and wondered if there was maybe something I needed to enable to make RENDER happy?

Thanks

[DRC]

I'm wondering if it needs a specific version of the RENDER extension.
I'll investigate. Can you clarify which specific version of CentOS 7
(cat /etc/redhat-release) and TigerVNC (rpm -q tigervnc-server) you are
using? I assume you're also using the latest TurboVNC? I'll compare
the version of RENDER used in TigerVNC and TurboVNC and see if there is
a discrepancy.

[sigwx314]

The system is on CentOS Linux release 7.4.1708 (Core)

with the Tiger VNC server version tigervnc-server-1.8.0-1.el7.x86_64

my TurboVNC build was from source using the dev branches in git (for turbovnc, libjpeg-turbo and virtualgl)

Thanks!

[DRC]

In that case, the problem may be the opposite of what I thought.  If you're using the dev branch, then the RENDER extension may be too new for CentOS 7.4.  Can you try the 2.2.5 version instead?  I'm just curious as to whether it experiences the same issue.  It would be odd for an application to demand an X11 extension that is older than a particular version, but I've seen stranger things.

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/9ada10f3-c961-4019-a09b-07063ffd73cen%40googlegroups.com.

[sigwx314]

Version 2.2.5 has the same warning from the client.

[DRC]

I'm officially flummoxed.  I ran rendercheck against both TurboVNC 2.2.5 and TigerVNC 1.8.0 (the system-supplied version in CentOS 7), and the results are basically identical.  The only differences had to do with the fact that TurboVNC has depth-15 Pixmaps and TigerVNC doesn't.  Both VNC servers use X Render v0.11.

Possible paths forward:

1. Contact the commercial software vendor and ask them how their software tests for X Render support.  That may give me a clue how to reproduce the issue locally.

2. Provide me with access to the commercial software so that I can install and test it locally.

3. Provide me with remote access via SSH so I can test the application remotely.

For Option 3, your organization would need to pay for my labor.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/8db8337f-2712-44e5-93b4-af0ded9f6c43n%40googlegroups.com.

[sigwx314]

Since you mentioned rendercheck I gave it a whirl, and I did see that the "Window format" shown for turbo was r5g6b5, while for tiger it was r8g8b8.    So I switched -depth to 24, and the warning about RENDER went away ... Seems odd to complain about render in that case, but that seems to clear it up :-)

[DRC]

TurboVNC uses depth=24 by default, so it wouldn't have been using depth=16 unless you explicitly configured it as such.  Don't do that.  TurboVNC supports color depths < 24 only for backward compatibility with ancient applications, but those modes do not perform optimally.  8-bit doesn't support JPEG at all, and in 16-bit mode, the pixels have to be up-converted to 24-bit prior to compressing as JPEG.  Thus, you don't save a significant amount of bandwidth by reducing the color depth (you save a lot more by increasing the chrominance subsampling or reducing the JPEG quality or increasing the compression level), and reducing the color depth creates visual artifacts and uses more CPU time than using depth=24.

In the future, if you encounter an issue with TurboVNC or any other free software package, please disclose any non-default settings you are using and try reverting those settings before you ask for support.  Our project is in a negative funding situation, and I cannot afford to spend hours of unpaid labor going on wild goose chases.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/0d715df8-69a1-435b-ad9e-661a3660ef8en%40googlegroups.com.