On 7/8/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
On Sat, 08 Jul 2006 02:10:09 +0100, Christian Limpach wrote:
>> I know, I added support for it. It was really painful to get right too
>> since the vga memory has to be flushed before the copyrect occurs (and
>> the system has to disallow more writes until the copyrect completes).
>
> Indeed, it was actually still a bit broken, relying on being able to send
> updates to the client even when the client hadn't requested an update yet.
> Also the case where the source or destination rects are not within the
> client's area is not really handled.
Actually, neither is really a problem. The VNC protocol does not specify
which FramebufferUpdates correspond to which FramebufferUpdateRequests.
There is a nasty race condition present in the VNC protocol related to
this caused by SetPixelFormat.
Actually they are:
- the first one defeats the VNC protocol which is supposed to be
client driven. If for example the client's windows is minimized, it
will no longer send update requests but your implementation keeps
flooding the client with updates it doesn't want or need.
- you can't really expect copy rect with the source rect outside of
the area which is being sent to client to work.
You get away with both at the cost of constantly updating a client
with updates, including updates outside of the area it has requested
but it doesn't work so well if you have 10 domains where the user has
minimized all but one window...
>> It's going to be even more painful in Xen since the cost of that
>> serialization is going to be greater.
>
> We thought we could pass the copyrect information as a hint and then only
> vnc-copyrect the areas which are still intact.
Yeah, I'm not convinced this will work all that well. The most common
CopyRect is window dragging. For X, the whole window is moved at once.
Under Windows, the window is broken into smaller rectangles and each are
moved individually. Because CopyRects always come in groups, and tend to
overlap, things get pretty nasty quickly. Plus, Windows tends to redraw
the border of a Window when it moves so depending on when you check,
things can be way off.
We would merge the group of copyrects by computing the source and
destination rects for the group of copyrects and then comparing the
source on the clients framebuffer with the destination in the updated
framebuffer. I wouldn't be surprised if it made the Windows
experience smoother.
>> >> Instead of switching bitmaps, why not just have the backend and
>> >> frontend share a bitmap and do atomic get/sets on it?
>> >
>> > Because we'd like to avoid atomic operations.
>>
>> Why? That seems odd to me.
>
> They're expensive on SMP systems?
Are they that expensive compared to what else is going on here? We're
talking about updates that occur at rather coarse granularities (10-15
times a second). Seems like the cost wouldn't make much of a difference.
Yeah, see my reply to Rik.
> Not sure, it could be an option. Might as well use VNC as the protocol
> then?
Perhaps. VNC is a little rough around the edges (things like the
SetPixelFormat race are a real pain). Would be nice to have something
that supported more advanced features though like YUV overlays.
The VNC protocol seems extensible enough. In any case, talk is cheap ;-)
christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home