On 5/6/11 12:10 PM, Arthur Huillet wrote: > I was under the impression that the server would send a framebuffer update > command, and that this could count as a "frame", even > if only 1% of the *pixels* are getting updated, from the user's point of view > it is still a complete frame, isn't it? > What I mean is that if the user displays a static application through VNC, > very little of the screen will be updated at every > frame, and we'll end up with a low pixel throughput while everything is going > perfectly fine, which would lead to making > incorrect decisions about image quality. Am I missing anything? > > In the case I am working on, the user will want to specify a target > "performance" (actually I will specify it for him but that's > besides the point). This performance can be measured in many ways, a common > way of measuring it in interactive applications is > FPS. What I would like to better understand is what metric we use to expose > to provide the user with the ability of specifying a > target performance that makes sense for him. > Full screen updates/second will work if you are playing a movie or a game, > but if you're running for example "gedit", you don't > really care as a user how many pixels are sent across the wire - you care > about your application's display being updated a > certain number of times each second. > > In any case, I am under the impression that the frame spoiling and automatic > quality adjustment cannot be kept completely > separate, because if the VNC server sends you 40 fullscreen updates per > second and you can only accomodate 20 with decent > quality, you're in trouble. > > My final objective is to specify "I want the user to be able to see 20FPS", > on the server or viewer side, or both, and have > TurboVNC behave automagically for this requirement to be met, taking into > account possible variations of network throughput as > the session runs. I think it's a feature that would be useful to many.
In the case of GEdit, in all likelihood the updated tiles are going to be sent using paletted or mono encoding, so the discussion of dynamic quality adjustment is moot. I don't really understand how the concept of frames/second has any meaning at all for such an application. With respect to 3D and video applications, a "frame" has a very definite meaning from the application's point of view. The problem is that this meaning is lost as the frames are translated into remote framebuffer updates sent by TurboVNC to the viewer. There is not necessarily a 1:1 correspondence between the two. TurboVNC could conceivably send one large framebuffer update for a single 3D/video frame, or it could send a bunch of small updates, or it could send only one small update if that's the only thing that changed since the previous frame. So, what we're trying to reconstruct on the viewer end is how a framebuffer update corresponds to a frame drawn by the application, and as far as I can tell, we can't do that. I do see your point regarding the fact that measuring an aggregate pixel throughput would not properly handle large variations in the number of pixels updated from frame to frame. Realistically, though, 3D and video apps will usually update most of the pixels in the window on every frame, so the pixel throughput should have a rough correspondence to application frame rate. If it errs on the side of caution and sets the JPEG quality lower than it really needs to be, that shouldn't be a problem, because it will do a lossless refresh once the motion stops. As far as client-side ALR, that's conceptually pretty easy. It would work similarly to the way it works on the server-- a separate thread would wake up on an interval and check whether the ALR timeout has elapsed since the last framebuffer update was received, and if so, it would send a lossless refresh request. I really want this to land in TurboVNC 1.1 and to remove ALR from the server. It'd be a lot nicer to have it configurable through the GUI instead of having to specify the ALR interval whenever you start the server. ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
