Den 2009-03-16 11:45 skrev Pierre Ossman:
On Mon, 16 Mar 2009 10:44:07 +0100
Peter Rosin wrote:
Hi Pierre!
There is also the WMVi pseudo-encoding (0x574d5669, or "WMVi" in FourCC)
to consider. A problem with this new proposal is that *both* WMVi and
this multihead scheme are "better than" the DesktopSize pseudo-encoding.
But the multihead scheme doesn't do the stuff that WMVi does (i.e.
handle server side pixel format changes). I fear that appempts to
implement support for both WMVi and this proposal will lead to undesired
complexity.
So, I'm asking for a way to incorporate server side pixel format changes
in this proposal so that it can superseed both WMVi and DesktopSize.
I don't see a huge gain from including it into these message. We could
just as well implement the server pixel format hint as another
pseudoencoding. Since it is a strict server-to-client communication, we
don't need to think about allocations in the more limited command space.
That said, there is one thing that I don't like about WMVi, and that is
the fact that the server changes the "wire" pixel format without a chance
for the client to say no. I would not mind at all if that was revised,
should a pixel format changes be added to this proposal, so that the
server instead simply informed that its preferred pixel format has
changed. The client would then be in full control of what pixel formats
it needs to support, and my feeling is that this is more in line with
the spirit of the RFB protocol.
That would be very against the RFB mentality, yes. But the wiki entry
you pointed to suggests that these encodings are just used for
"offline" rendering. At that point there is no possibility for the
server to adjust to the client's need, so you have to mandate that the
client will use the server's native format.
WMVi is implemented by QEMU, gtk-vnc, ggivnc and more, so it's certainly
not just offline rendering. I don't know why QEMU selected WMVi for
adding pixfmt notifications, but they did. If you want to get full
use out of QEMU you need to implement WMVi.
Even if it wouldn't add needless complexity if the server were to send
a WMVi rect for some changes and a ExDesktopSize rect for some other
changes and perhaps two rects for some classes of changes, I still think
there is value in an "advisory" notification that the server has changed
its preferred pixel format, and this seems like a good opportunity to
sneak that into the RFB protocol ;-)
I agree that such a hint could be useful. I'm not convinced it needs to
be included in these messages. Besides, a server and client should
implement support for all variants anyway to give good backwards
compatibility.
I only suggested it since WMVi is in-use already, and having one superior
way to handle desktop changes is always going to be easiest, then the other
methods become legacy. You can also focus on implementing each of them
separately, and not on how they interact with each other. Sure, for
ultimate support, a client *should* handle a server switching between
DesktopSize and ExtendedDesktopSize, but both you and I know that
a server which has a client supporting both is very unlikely to switch
between them. It will go with ExtendedDesktopSize and be done with it.
But if the server also sees WMVi support there are more than one way to
send changes (WMVi first or WMVi last), and it then becomes harder to
verify that a client behaves correctly in all cases, since the server you
have available might not behave similar to the one next door and which you
have not tested against. Adding pixel format change support in the
ExtendedDesktopSize will end all that - there will be a simple path and
all sane servers will follow it. Less headaches for everybody.
And lastly, some comments on details in the proposal:
There is no way for the server to tell a client how it can change its
SetDesktopSize message so that it gets something that is ok for the
server. If e.g. the server has some resource limit that prevents it from
making framebuffers wider than 2048 pixels (just an example, the example
has no bearing on any particular HW), then the server has no way to
indicate to the client that it must keep below that limit. One way to
solve that would be for the server to fill in the ExtendedDesktopSize
rect with values that may work better when y-position is non-zero,
instead of simply echoing the current state (which the client should
already know). But perhaps that would be too complex. My main point is
that it's very limitied to only have 16 bits (the y-position) to
describe a problem. Perhaps an error string?
Strings are not machine parsable, nor translatable (unless you mandate
exactly what they should say, at which point you might as well use a
code for them).
And yet the protocol is already full of strings, so you have to deal with
that already. But if you dislike strings so much, what was wrong with the
machine readable proposal? Just because the server has a way to report
back something that should work doesn't mean it has to do much work to
do so, a lazy server-side implementation can send back the currently
active config and be done with it.
When it comes to this specific problem, the current protocol suggestion
should already handle it:
"The x-min, y-min, x-max, and y-max indicates server imposed limits of
the framebuffer. The client can use this information to indicate to
the user when resizing (using SetDesktopSize) is possible."
Ah, right. Bad example... So, take some other example: there is some limit
(for whatever stupid reason) on the server so that it supports maximum
17 screens. Or it might not support overlapping screens. Or all screens
have to be the same size. Use your imagination...
The x position of the pseudo-rect indicates the "reason for the change",
and an ExtendedDesktopSize pseudo-rect should also be sent in response
to non-incremental FrameBufferUpdateRequests. I'm missing "non-i FBUR"
as a reason in the enumeration (even if that isn't a /change/ as such).
Ah, sorry. The intent was to have 0 be roughly "server side change" and
include the non-i FBUR. That meaning got lost in some revision.
How about this replacement text:
0 - The screen layout was changed via non-RFB means on the server. For
example the server may have provided means for server-side applications
to manipulate the screen layout. This code is also used when the client
sends a non-incremental FrameBufferUpdateRequest to learn the server's
current state.
Works fine for me. Thanks!
Cheers,
Peter
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
