Den 2009-05-15 12:20 skrev Pierre Ossman:
> On Thu, 14 May 2009 15:56:35 +0200
> Peter Rosin <p...@lysator.liu.se> wrote:
>
>> Den 2009-05-11 13:27 skrev Pierre Ossman:
>>> That sounds a bit like "this look like crap, but pff, what do I
>>> care?" :)
>> Well, that's stretching it, but exactly one person has commented
>> (in public) on your encoding and you have shot down all
>> suggestions I have made (not counting editorial nitpicks). So,
>> what do you expect?
>>
>
> I can be a bit confrontational, but it was not my intention to put you
> off and I apologize if I've been too harsh. I really value your input
> to the discussion.
The conversation as such has been pleasant. I do not perceive you as
confrontational, I was just getting tired of not getting any output
from my input...
> Although I didn't incorporate you changes in this extension, I have
> been thinking about them and I think they should be added, but as
> separate extensions. As such, your comments have been very valuable to
> me.
Only one of my suggestions qualifies as a separate extension. Or?
When you say "separate extensions" I assume you are referring to
my WMVi/pixfmt suggestion. Since the only way to change the
server preference of the pixfmt is the WMVi encoding (either that
or reconnecting, bleah), let us see what it will lead to when you
are using both WMVi and EDS.
The server will be the easy part to implement, so consider the
client impact (keep the client easy, remember): You have said
nothing about WMVi in the EDS spec, so the client has to assume
that a WMVi rect can appear at any point.
1) WMVi rect appears in an update without any EDS rect, the FB size
matches the previous full FB size.
Easy, just assume the screen layout stays the same and that the
only thing that has changed is the pixfmt.
2) WMVi rect appears in an update without any EDS rect, the FB size
doesn't match the previous full FB size.
Hmm, what to do. Stupid server. Drop all screens and show the
FB according to the WMVi rect I guess...
3) WMVi rect appears in an update with an EDS rect afterwards, the
FB size is updated and the size in the WMVi rect matches the
size in the EDS rect.
On reception of the WMVi rect, the client should wait to see
if an EDS rect is appearing in this update and combine the two
into one operation instead of ending up in case 2.
4) WMVi rect appears in an update with an EDS rect afterwards, the
FB size is updated but the size in the WMVi rect matches the
previous FB size.
On reception of the WMVi rect, the client could wait to see
if an EDS rect is appearing in this update and combine the two
into one operation. It could also do as in case 1.
5) EDS rect appears in an update with a WMVi rect afterwards, the
FB size is maybe updated and the size in the WMVi rect matches
the size in the EDS rect.
See 1, but it would probably be better to combine the two
operations as in 3 or 4.
6) EDS rect appears in an update with a WMVi rect afterwards, the
FB size is maybe updated but the size in the WMVi rect doesn't
match the size in the EDS rect.
Hmm, what to do. Stupid server. Drop all screens and show the
FB according to the WMVi rect I guess...
I see two problems for the client. It has to deal with the full
update as a single entity in order to do the combinations from
cases 3, 4 and 5. It is not possible to deal with updates on a
rect by rect basis. The FB pixfmt and the FB size are also
tightly coupled. Sure, on the typical windowed desktop you will
typically have 16 or 32 bits and not bother with anything else.
But if you have a client that can render directly into /dev/fb
(or equivalent), the available FB sizes are strongly dependent
on the desired pixfmt. For such a client it will be double work
to first find a good graphics mode using one pixfmt only to redo
it right away with a different pixfmt. The client will gain from
combining the EDS rect and the WMVi rect and it would be so much
easier if the two were combined into one rect from the server.
It will also be quite hard to test all the above cases. Where
will you find a server that can do all cases? Yeah, I know, you
could write a testsuite for your client, but if there were only
one case it would get tested for free by regular users, and not
only when someone runs some obscure testsuite.
If you do specify when and how a WMVi rect may appear in the
presence of EDS rects, you will get away from many of the above
difficulties. My suggestion is to require that WMVi rects are
only sent alone or directly after an EDS rect and that FB
resizes using the WMVi message are disallowed (i.e. allow
cases 1 and 5). The important thing is to disallow cases 2, 3
and 6, but I think you should disallow case 4 (and maybe even
case 1) while you have a chance.
>>>> Oh, and I still think it would cleaner to hook into the tight
>>>> extension for the start-up difficulties.
>>>>
>>> I agree, but I'm concerned it will severely limit how many will
>>> implement it. We could redefine the behaviour in the future, given
>>> that the server and client have negotiated via some other mechanism
>>> (like tight).
>> No good, you would still need to keep the old code to cope with
>> the old style negotiation to stay compatible all the legacy
>> installations and the flourish of alternate implementations. I
>> predict that you will stick with whatever negotiation you start
>> out with.
>>
>
> We could avoid the extra roundtrip though, so there is some gain
> outside of the complexity.
Are you worried about a few extra roundtrips during connection
setup?
Cheers,
Peter
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
