On 24.09.2013 13:17, Pierre Ossman wrote:
On Tue, 24 Sep 2013 13:09:46 +0200
Christian Steinle <christian.stei...@unicon-software.com> wrote:

Hi Pierre,

as I understand correct, the SetDesktopSize functionality is located 
between the remote and the local framebuffer content. This connection I 
have not touched, because this is not possible in my opinion due to 
direct RW framebuffer access for partial rectangular framebuffer updates 
and thus damage regions. So I have simply implemented a scaling factor 
for drawing the local framebuffer into the scaled viewport with respect 
to the scaled damage regions. So the implementation considers just three 
different points:

  1) Get the viewport size independent of the framebuffer size [EASY]

This is the difficult part. :)

If you resize the viewport right now, the client will send a
SetDesktopSize to make the server end track the client's resolution.
There needs to be a sensible user interface for these two conflicting
methods of resolving a different local and remote size.
Maybe I did not get anything. I thought that the parameter remoteResize=0 will skip that functionality. And I have implemented additionally the parameter localScaling=1 for the scaling topic. So I have made simply an additional checkbox in the optins->screen tab. I think one has to be able to enable just one or the other, but even both enabled seems to be operational at the logical end, because remote resize simply wins. But this might be not the case on other platforms.

      
  3) Implement the scaled drawing: (Win32: StretchBlt(...) instead of 
BitBlt(...) [EASY] / X11: Use nearestNeighbour algorithm and separate 
rectangular XImage for update region [EASY and FAST but bad quality] / 
OSX: [NOT DONE])
Might want to consider using OpenGL for scaling. Or at least XRender on
X11.
Yes of course, but since i am not familiar with both, this is too time consuming for me (I tried it and then skipped it ;)

So I will try to get some patches on that topic only in the next future 
and send it to you. Maybe you can have a look at it to implement an 
improved version into the repository code?
Sure. But the crucial issue is the first one IMO; how to present this
in a sensible manner to the user.

Rgds


--

Dr. Christian Steinle 
System Architect Linux OS 

Unicon Software GmbH 
Philipp-Reis-Str. 1 
76137 Karlsruhe 
Germany 
Tel. +49 (0)721 96451-0 
Fax +49 (0)721 96451-43 
Email: christian.stei...@unicon-software.com
Web: www.unicon-software.com 

This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to