Den 2009-03-16 15:00 skrev Pierre Ossman:
On Mon, 16 Mar 2009 13:29:38 +0100
Peter Rosin wrote:
Den 2009-03-16 11:45 skrev Pierre Ossman:
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.
Annoying. Do they also rely on putting the conversion requirements on
the client?
Yes. If a client claims support for WMVi, it has to support all pixfmts
(or disconnect on reception of something unlikeable).
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.
I'm not sure I see the complexity. If a server wants to support all
three methods, it can send all three rects. The only requirement that
must hold is that the information in the different versions do not
conflict.
Admitted, having WMVi for just sending hints about the server's native
pixel format can be a bit heavy. But I think it would be better
replaced by a pseudoencoding that does only just that. Including that
information here just makes the screen geometry handling seem more
complex.
(In a perfect world I'd have framebuffer size and virtual screen setup
be completely separate as well, but that would mean that we would need
two client-to-server commands and that would be wasteful given the
limited space of command codes.)
Ok, you clearly don't want pixfmt mixed into this, so I'm dropping that
ball on the floor.
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.
It's just the authentication as far as I can see. And that something in
the existing protocol is bad is hardly an argument for making additions
equally bad.
Ok.
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.
The idea isn't fundamentally bad, it's just that describing
restrictions is a can of worms and I don't think its a good idea to add
features that you don't have a plan as to how they should be used.
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...
Indeed, but describing such limitations can be very difficult. How do
you describe the non-overlapping requirement for example?
I don't see the method of requesting one thing and potentially getting
something completely different back as a decent solution. In most cases
it will just be plain confusing.
Could you describe how the client could suitably react to such a
response?
I wasn't proposing that the exact restrictions were described. I didn't
propose that the server response would actually be used, it would just
be a hint so that the client would have at least some request that worked.
But the client would probably need to adjust the server reply further.
An example (using monospace font):
Server has two screens 1024x768, side-by-side, fb-size 2048x768.
---------------------
| | |
| | |
| | |
---------------------
Client the asks for the initial two screens, plus a third screen 800x600
which is halfway overlapping the rightmost screen, fb-size 2448x768.
-------------------------
| | | | |
| | | | |
| | ----|----
---------------------
Server says "no" (since it can't handle overlapping screens) and informs
the client that it could change its request to not have any overlaps,
i.e. make the third screen only 400x600, fb-size still 2448x768.
-------------------------
| | | |
| | | |
| | |----
---------------------
The client can then do what it wants with that info. If it takes it, it
could render on only half its third screen.
Or, the server says "no" (since it can't have any fb-areas not covered by
any screen) and informs the client that is could change its request to not
have any "white" areas, e.g. make all screens 600 pixels high, fb-size
2448x600.
-------------------------
| | | | |
| | | | |
-------------------------
If the client accepts this server suggestion, if could leave black areas
at the bottom of its first two screens (between 600 and 768).
But perhaps it's useless, since the server has just about no idea how
to best adjust the client request into something that is usable for the
client. My idea was that it adjusts things down (or up, but I think down
is saner as the client is probably bound by HW limits) until the request
is within server imposed limits, then tell the client what it ended up
with and letting the client do whatever it wanted with that info. How
useful that info would be for the client would largely be up to the
server implementation. The laziest of servers would just state the
current settings which by definition should be ok to request, but be
approximately useless for the client.
Since it is nearly impossible to envision all possible server side
limitations, we shouldn't even try. Instead, let the server come up with
one possible workaround for the client, but never force that suggestion
on the client. The client can always request something completely
different, should it dislike the server suggestion.
I'm starting to repeat myself, tell me to stop if you're tired of me...
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
