Having fully implemented the X RANDR extension in the evolving build, I did not see any way to implement server-side scaling as part of that feature. X RANDR scaling does seem to be a hardware-specific thing, so we would have to minimally emulate it in the VNC code, as well as supporting 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 > "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 ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
