http://sourceforge.net/p/libjpeg-turbo/patches/40/
On 7/17/13 11:58 PM, Bharatkumar Sharma wrote:
> Thanks for the excellent explaination. I got all the answers I
> had, there might be issues with the design I was thinking .
> I am convinced that implementing at lower lever looks like more
> prom
Thanks for the excellent explaination. I got all the answers I had, there
might be issues with the design I was thinking .
I am convinced that implementing at lower lever looks like more promising
solution.
Regarding the OpenCL implementation you have talked about. Is it already in
implementation
The problem with what you're proposing is that, if the pixels are not
read back by VirtualGL, then the VNC X server will not have a copy of
the pixels in its virtual framebuffer. The lossless refresh, ALR, and
interframe comparison features wouldn't work properly, since those
features require
The final Goal is to do JPEG compression done by TurboVNC using libjpeg on
GPU and not on CPU and in order to do that below is the given setup.
We have a setup where VirtualGL interrupts all GLX calls and renders
offline in a pbuffer on a NVIDIA GPU. In normal setup VirtualGL reads this
rendered i
Please explain what you're trying to accomplish.
On Jun 20, 2013, at 1:54 AM, Bharatkumar Sharma
wrote:
> Hi,
>
> I am new to VirtualGL and TurboVNC. We have requirement that VirtualGL should
> not readback the rendered image and TurboVNC before compressing the rendered
> image should get h
Hi,
I am new to VirtualGL and TurboVNC. We have requirement that VirtualGL
should not readback the rendered image and TurboVNC before compressing the
rendered image should get handle to this pbuffer.
After reading the VirtualGL guide I see that setting VGL_READBACK will
solve the first part of pro