"Christopher Saul" <[EMAIL PROTECTED]> wrote: > "Curt Cox" <[EMAIL PROTECTED]> wrote: > > From the doc, THINC requires Xfree86 to be running and needs some > kind of client software on the client device. This means it > requires some kind of OS at this stage.
THINC needs an OS on the server to host its XFree86 X server, just as Sun Ray needs an OS (Solaris or Linux) to host its X server and other SRSS components. On the client side the THINC viewer was implemented as an application over a traditional general-purpose OS but that's just for convenience. It's no stretch at all to imagine a THINC viewer running in dedicated hardware over a small embedded OS, just like Sun Ray. > > I wasn't talking about adopting the entire protocol, but merely > > specific details from it. > > > > See page 11 for an example: > > "While Sun Ray and THINC use a similar multicommand protocol, Sun > > Ray is unable to leverage..." The rest of that sentence happens to be wrong. I'm not sure whether that makes this a good example or a bad one. > > Is offscreen drawing somehow impossible within the current Sun > > Ray architecture? It's not impossible at all. Whether it's actually useful is a different question. I can see how it could reduce latency, which is that claim that THINC makes, but it's not free. The X server ends up doing a lot of extra work, much of which may never be used. Netscape and its heirs are very fond of creating huge numbers of offscreen pixmaps, many of which never get drawn onto the screen. Is it a good use of CPU time (and memory) to pre-render those pixmaps just in case some of them do eventually get shown? What's the impact of pre-rendering lots of pixmaps on a machine that is hosting lots of sessions? It's very hard to draw solid conclusions about the goodness of the THINC approach versus the Sun Ray approach from that paper, there are just so many factors that are different or are unaccounted-for. One thing that is clear (it's been clear for a long time) is that Sun Ray's video performance is weak. The reason is that the player application ends up having to use ordinary X pixmaps to play the video frames, and it has to send those pixmaps through the X server. There's a ton of overhead in this process, it's just the wrong tool for the job. The annoying thing is that Sun Ray actually has some interesting technology in this area; it supports the notion of having the player application bypass the X server completely and render the video directly to the Sun Ray. This is a huge win both for the performance of that one video stream and for the number of concurrent streams you can drive from one machine. The bad news is that this approach requires getting into the guts of the player application and writing an output codec specifically for Sun Ray. This turns out to be impractical in the real world, it's been released only for Sun's now-dead ShowMeTV product. One of the things on the wish list for a future SRSS release is to implement the XVideo extension in the Sun Ray X server. This is the same extension THINC used, it allows the player to send video data through the X server with far lower overhead than using X pixmaps. It's not as good as rendering directly from the player to the client but it has the huge advantage of being supported by lots of players and not requiring a client-specific codec for every player. We're in the middle of haggling over the feature list for the next release, so now would be an excellent time to let your Sun contacts know what features are important to you. If lots of people tell us that video is important then that increases the chances of XVideo happening. OttoM. __ ottomeister Disclaimer: These are my poinions. I do not speak for my employer. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
