Ah, yes, sorry for the confusion. The feature I'm describing is called "remote desktop resize" or "remote framebuffer resize", which just resizes the remote desktop. However, I note that the XRANDR extension, which I will have to add anyhow to support remote desktop resize, also supports scaling. I don't know if it would be possible to implement the scaling feature with VNC, since that feature seems to be a function of the monitor output. I'll look into it, though. Barring that, implementing the feature in the VNC code would be very difficult, since it would require fundamental changes to all of the encoders, as well as a new RFB extension.
On 2/27/13 4:00 AM, Paul Melis wrote: > Hmm, the things you describe here sound like something different than > what I thought you were going to implement :) > > I thought the new feature was about resizing the framebuffer just before > it is sent to the client. This would allow the server to use a > high-resolution framebuffer, which gets scaled down before transmission > to clients that can't handle it, while still allowing clients that can > use the high resolution to receive such a framebuffer. > > But what you describe is (I think) letting the client set a different > framebuffer size for the remote desktop on the server, right? > > On 25-02-13 23:57, DRC wrote: >> It's already in the RFB protocol, and both the Java and Windows TurboVNC >> viewers already support it. Historically, the RFB new framebuffer size >> extension was used with Windows VNC servers, including the Windows >> TightVNC Server, as a way of communicating changes in the size of the >> remote desktop to the client. More recently, TigerVNC implemented >> remote desktop resize in their Unix VNC server using the XRANDR >> extension, so our implementation will be based on that. It is possible >> to send resize requests from the viewer as well (our new Java viewer >> already has that capability.) I need to study it and figure out how >> best to allow that capability to interact with our existing window >> resize and full-screen logic. >> >> On 2/25/13 6:38 AM, Paul Melis wrote: >>> Just chiming in here, but that's an awesome feature to have! Is this >>> something that the RFB protocol already supports or would it be a >>> TurboVNC-specific extension? I guess I mean: is there already a way for >>> a client to specify the resolution it wants the server to provide? >>> >>> Regards, >>> Paul ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
