On Thursday 02 September 2010 15:27:06 [email protected] wrote: > Send SunRay-Users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.filibeto.org/mailman/listinfo/sunray-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SunRay-Users digest..." > > > Today's Topics: > > 1. VDI 3.2 Preffered server ? (Dark Bass) > 2. Re: Server Side Graphics Processing (Craig Bender) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 2 Sep 2010 15:22:53 +0200 > From: Dark Bass <[email protected]> > To: SunRay-Users mailing list <[email protected]> > Subject: [SunRay-Users] VDI 3.2 Preffered server ? > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > I am getting this messeges > > ray2 cacao[1351]: [ID 702911 daemon.warning] > com.sun.vda.service.client.ClientRequestWorker.run : Failed executing > vda-client request: serverList(user=u...@domain, token=pseudo.002128409110, > clientAddress=127.0.0.1): No preferred servers found for u...@domain > [ExitCode=15] > > what does this mean or where do i set a preffered server ? > > thanx > Darko > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://www.filibeto.org/pipermail/sunray-users/attachments/20100902/161f3 > 7ad/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 02 Sep 2010 07:26:31 -0700 > From: Craig Bender <[email protected]> > To: [email protected], SunRay-Users mailing list > <[email protected]> > Subject: Re: [SunRay-Users] Server Side Graphics Processing > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Craig, > Today, nothing in SRSS or VDI will use a GPU at any level in the stack > (Sun Ray Presentation Layer, Hypervisor, vRDP). Thank you so much for your definitive answer. > Not sure what Viz product pitch you had, but there were two "solutions". > One was basically dedicated solution which I believe was an actual > product and the other was a "shared" solution concept that was in early > stages. > Both were aimed at recapturing the traditional (legacy?) Sun Workstation > market, and Solaris only (No Linux, no windows). Neither exist today, > at least as an offering from Oracle (I think parts of the shared Viz > were "open"). I see now. The presentation does talk about Solaris 10 as the core OS > > We are constantly looking at new ways to bring affordable, scalable > solutions to Sun Ray, but pricing some of the dedicated GPU solutions > blows me away and can't really understand why anyone would pay $3-5K to > replace a PC on the desk. The shared concept is more interesting. The shared concept if made to work would make SunRays and Sun/Oracle offering unbeatable. SunRay's are nearly there anyway :-) Thank you > > On 9/2/10 5:44 AM, Alex Brulo wrote: > > Hi guys, > > > > I am second here for pleading ignorance, so bear with me please. > > My question as follows: (hope someone from VDI team > > would put all my ignorance to rest :-) > > I have quiet powerful 4600 M2 with 256GB of ram > > and build in ATI graphic adapter serving 50 VM's (mostly Linux, but there > > are some windows) in a single server configuration. > > a) Is there any point to upgrade and install > > top of the range supported nVidia adapter > > and run it in Multi-GPU FrameRendering or CLI ? > > b) will it affect VB/srs performance or is it all irrelevant ? > > I still have the presentation Sun-visualization.ppt from not so distant > > past. One of the slides had a sample configuration using 4600 M2 and 2 > > nVidia Model 4 Quadro Plexes with 6GB of total frame buffer. I was > > wondering if a similar type of configuration could be applicable > > (Solaris 10 and VDI 3.2) Thanks > > > > On Thursday 02 September 2010 01:07:28 [email protected] wrote: > >> Send SunRay-Users mailing list submissions to > >> [email protected] > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://www.filibeto.org/mailman/listinfo/sunray-users > >> or, via email, send a message with subject or body 'help' to > >> [email protected] > >> > >> You can reach the person managing the list at > >> [email protected] > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of SunRay-Users digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: Top 3 of new Sun Ray features (Craig Bender) > >> 2. Re: Top 3 of new Sun Ray features (Ivar Janmaat) > >> 3. Re: Top 3 of new Sun Ray features (Wim Coekaerts) > >> 4. Server Side Graphics Processing (was: Top 3 of new Sun Ray > >> features) (David Bullock) > >> 5. Regarding Flash 10 Content (Craig Bender) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Wed, 01 Sep 2010 12:57:48 -0700 > >> From: Craig Bender<[email protected]> > >> To: SunRay-Users mailing list<[email protected]> > >> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >> Message-ID:<[email protected]> > >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> > >> Folks, > >> I apologize if anyone took this to mean we are not pursuing local decode > >> solutions, or that I was trying to push Ivar away from wanting local > >> decode. That is neither the case, or my intent. > >> > >> I was simply trying was to highlight that while RCA may be more > >> "expensive" in terms of scalability, it has it's place when usability is > >> a concern. > >> > >> At the very least, RCA buys us time to further develop and enhance our > >> existing technologies such as direct decode without impacting end user > >> experience. > >> > >> On 9/1/10 10:11 AM, Craig Bender wrote: > >>> On paper direct decode looks like a better option, and in some cases it > >>> is indeed the better option. Like: > >>> > >>> A purpose built hardware device, or features in an existing devices > >>> chipset, dedicated to video processing. Typically these only support a > >>> few formats due to putting codec either in the hardware on in the RTOS. > >>> Rarely do the codecs in the device support every possible encoding > >>> option, so even video that is "supported" at the higher level of the > >>> spec, might not play on device. Codec development takes time, and in > >>> many cases the vendors of the purpose built device need to license > >>> technology from 3rd parties even though there is a free (to use) > >>> Windows codec. The biggest problem with the purpose built device > >>> though, is it usually does only one thing. And if it does more than one > >>> well it usually costs as much as a PC, but doesn't exactly replace your > >>> PC. > >>> > >>> The other would A device that allows the somewhat easy installation of > >>> readily available codecs. Usually this means windows, but definitely > >>> means a fat OS. I say somewhat easy installation because things rarely > >>> just work. You might get prompted to install a codec, you might have to > >>> manually research what codec is needed. There might not be a codec for > >>> your OS available, or it might not be free. > >>> > >>> Then you take thin clients. They have the problems of the purpose built > >>> device, with the added the complexity that they really weren't built > >>> for video. Sure the chipset may have some codec support (usually parts > >>> of a codec that are "free") but not only do you have to write firmware > >>> to access the codec and software to stream it down to them, but you > >>> have a problem with updates to the video format spec itself. They are > >>> constantly changing and you wind up having to either replace the > >>> hardware or someone has to start writing software drivers, and > >>> eventually you have locked down PC. > >>> > >>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>> display almost any desktop on the same device), RCA future proofs the > >>> multimedia from the codec required on the display device. > >>> > >>> It may require more processing at the hypervisor layer, or some cases > >>> the Sun Ray Server layer, and it may not be as efficient bandwidth wise > >>> as direct decode, but it makes things usable. And at the end of day, > >>> it's not usable, it's not worth buying. > >>> > >>> > >>> > >>> > >>> The problem with purpose built hardware is that > >>> > >>> On 9/1/10 8:33 AM, Ivar Janmaat wrote: > >>>> Hello, > >>>> > >>>> The advantage of MMR is that it uses less resources on the server > >>>> since it is offloading the decoding to the Sun Ray. > >>>> This will scale better then vrdp. Although not yet tested I suspect > >>>> MMR will use less bandwidth which would give better performance over > >>>> WAN. > >>>> > >>>> #3 means indeed a separation between the system disk c: and the > >>>> documents and settings disk d: > >>>> I used this a lot in implementations with Virtual Bridges since they > >>>> have had this feature already 10 years ago. > >>>> I noticed that you can not select this feature if you use LDAP or > >>>> Novell directory servers. It can only be used in combination with AD. > >>>> > >>>> Kind regards, > >>>> > >>>> Ivar > >>>> > >>>> Wim Coekaerts schreef: > >>>>> have you tried vdi3.2 with vb as the hypervisor and vrdp ? > >>>>> > >>>>> it plays flash just fine for windows xp,7, linux etc > >>>>> > >>>>> not sure what #3 means. I guess you mean the new feature in 3.2 where > >>>>> you can replace only the system disk and keep the user disk. I didn't > >>>>> realize that didn't work with ldap > >>>>> > >>>>>> Number 1: > >>>>>> Flash 10 content support in MMR on Windows XP. > >>>>>> > >>>>>> Number 2: > >>>>>> MMR support for Windows 7 > >>>>>> > >>>>>> Number 3: > >>>>>> Personal data disk for other directories than AD. > >>>>>> > >>>>>> I hope this helps to give some direction for future development. > >>>>>> > >>>>>> Kind regards, > >>>>>> > >>>>>> Ivar Janmaat > >>>>>> _______________________________________________ > >>>>>> SunRay-Users mailing list > >>>>>> [email protected] > >>>>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>>> > >>>>> _______________________________________________ > >>>>> SunRay-Users mailing list > >>>>> [email protected] > >>>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>>> > >>>> _______________________________________________ > >>>> SunRay-Users mailing list > >>>> [email protected] > >>>> http://www.filibeto.org/mailman/listinfo/sunray-users > >>> > >>> _______________________________________________ > >>> SunRay-Users mailing list > >>> [email protected] > >>> http://www.filibeto.org/mailman/listinfo/sunray-users > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Thu, 02 Sep 2010 00:13:17 +0200 > >> From: Ivar Janmaat<[email protected]> > >> To: SunRay-Users mailing list<[email protected]> > >> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >> Message-ID:<[email protected]> > >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> > >> Hello Craig, > >> > >> I appreciate your input! > >> > >> A few years ago my opinion on the implementation of MMR was rather > >> negative because in my opinion the ultimate ultra thin client should > >> only handle generic codecs not specific Flash and MS codecs of a > >> specific version. The RCA method is much more in line with my thoughts > >> on how the ultimate ultra thin client should operate. You definitely > >> don't want to end up with an obese client stuffed with all sorts of > >> codecs. > >> > >> So I like the Virtualbox - RCA - Sun Ray combination. Since Virtualbox > >> supports 3D acceleration, this combination can be very strong. > >> (I would like to see some sizing figures on the 3D acceleration though) > >> > >> At this time however the VM market is still dominated by VMWare and KVM > >> type VDI solutions which come with all sorts of application management > >> tools. > >> If you want to position the Sun Ray as a client for those VDI > >> infrastructures, you need something else than vrdp (RCA). > >> This is where MMR kicks in. Other options are also possible like pcoip > >> or spice. I have discussed those before. > >> The problem with MMR is that it is badly crippled since there is no > >> Flash 10 content support at this time. > >> It would be a good idea to put Flash 10 content support in MMR before > >> Flash 11 arrives. > >> Then the Sun Ray would also be a good client for current VDI locations > >> where they don't use Virtualbox. > >> > >> So eventually it is not only a technical choice. It is also a choice > >> between selling Sun Rays solely with Virtualbox or selling it also with > >> other VM solutions. > >> I think the broker function of the Sun Ray is unique in the market. So I > >> would favor superb connection protocols to all VM/VDI solutions. This > >> would enhance the broker function even further and lift the product > >> above other offerings in the market. That is why I asked to fix the > >> crippled MMR functionality by supporting Flash 10. > >> > >> If Oracle however does not fix the MMR then I need to conclude that > >> Oracle has already decided to sell Sun Rays only with Virtualbox. > >> That would limit the broker function of the Sun Ray server which > >> basically means that the solution will become the same as all other > >> solutions in the market. > >> With head to head competition it will than be much harder to build large > >> volume Sun Ray sales. > >> > >> Kind regards, > >> > >> Ivar Janmaat > >> > >> Craig Bender schreef: > >>> Folks, > >>> I apologize if anyone took this to mean we are not pursuing local > >>> decode solutions, or that I was trying to push Ivar away from wanting > >>> local decode. That is neither the case, or my intent. > >>> > >>> I was simply trying was to highlight that while RCA may be more > >>> "expensive" in terms of scalability, it has it's place when usability > >>> is a concern. > >>> > >>> At the very least, RCA buys us time to further develop and enhance our > >>> existing technologies such as direct decode without impacting end user > >>> experience. > >>> > >>> On 9/1/10 10:11 AM, Craig Bender wrote: > >>>> On paper direct decode looks like a better option, and in some cases > >>>> it is indeed the better option. Like: > >>>> > >>>> A purpose built hardware device, or features in an existing devices > >>>> chipset, dedicated to video processing. Typically these only support a > >>>> few formats due to putting codec either in the hardware on in the > >>>> RTOS. Rarely do the codecs in the device support every possible > >>>> encoding option, so even video that is "supported" at the higher level > >>>> of the spec, might not play on device. Codec development takes time, > >>>> and in many cases the vendors of the purpose built device need to > >>>> license technology from 3rd parties even though there is a free (to > >>>> use) Windows codec. The biggest problem with the purpose built device > >>>> though, is it usually does only one thing. And if it does more than > >>>> one well it usually costs as much as a PC, but doesn't exactly replace > >>>> your PC. > >>>> > >>>> The other would A device that allows the somewhat easy installation of > >>>> readily available codecs. Usually this means windows, but definitely > >>>> means a fat OS. I say somewhat easy installation because things rarely > >>>> just work. You might get prompted to install a codec, you might have > >>>> to manually research what codec is needed. There might not be a codec > >>>> for your OS available, or it might not be free. > >>>> > >>>> Then you take thin clients. They have the problems of the purpose > >>>> built device, with the added the complexity that they really weren't > >>>> built for video. Sure the chipset may have some codec support (usually > >>>> parts of a codec that are "free") but not only do you have to write > >>>> firmware to access the codec and software to stream it down to them, > >>>> but you have a problem with updates to the video format spec itself. > >>>> They are constantly changing and you wind up having to either replace > >>>> the hardware or someone has to start writing software drivers, and > >>>> eventually you have locked down PC. > >>>> > >>>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>>> display almost any desktop on the same device), RCA future proofs the > >>>> multimedia from the codec required on the display device. > >>>> > >>>> It may require more processing at the hypervisor layer, or some cases > >>>> the Sun Ray Server layer, and it may not be as efficient bandwidth > >>>> wise as direct decode, but it makes things usable. And at the end of > >>>> day, it's not usable, it's not worth buying. > >>>> > >>>> > >>>> > >>>> > >>>> The problem with purpose built hardware is that > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Wed, 01 Sep 2010 16:07:40 -0700 > >> From: Wim Coekaerts<[email protected]> > >> To: [email protected] > >> Subject: Re: [SunRay-Users] Top 3 of new Sun Ray features > >> Message-ID:<[email protected]> > >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> > >> we are improving that as well... (rdp rdp7 rca etc) > >> > >> I would agree with your vmware comment but seriously disagree with the > >> kvm/spice stuff. that's still no where and I can tell you that there is > >> no interest there. > >> > >> On 09/01/2010 03:13 PM, Ivar Janmaat wrote: > >>> Hello Craig, > >>> > >>> I appreciate your input! > >>> > >>> A few years ago my opinion on the implementation of MMR was rather > >>> negative because in my opinion the ultimate ultra thin client should > >>> only handle generic codecs not specific Flash and MS codecs of a > >>> specific version. The RCA method is much more in line with my thoughts > >>> on how the ultimate ultra thin client should operate. You definitely > >>> don't want to end up with an obese client stuffed with all sorts of > >>> codecs. > >>> > >>> So I like the Virtualbox - RCA - Sun Ray combination. Since > >>> Virtualbox supports 3D acceleration, this combination can be very > >>> strong. (I would like to see some sizing figures on the 3D acceleration > >>> though) > >>> > >>> At this time however the VM market is still dominated by VMWare and > >>> KVM type VDI solutions which come with all sorts of application > >>> management tools. > >>> If you want to position the Sun Ray as a client for those VDI > >>> infrastructures, you need something else than vrdp (RCA). > >>> This is where MMR kicks in. Other options are also possible like pcoip > >>> or spice. I have discussed those before. > >>> The problem with MMR is that it is badly crippled since there is no > >>> Flash 10 content support at this time. > >>> It would be a good idea to put Flash 10 content support in MMR before > >>> Flash 11 arrives. > >>> Then the Sun Ray would also be a good client for current VDI locations > >>> where they don't use Virtualbox. > >>> > >>> So eventually it is not only a technical choice. It is also a choice > >>> between selling Sun Rays solely with Virtualbox or selling it also > >>> with other VM solutions. > >>> I think the broker function of the Sun Ray is unique in the market. So > >>> I would favor superb connection protocols to all VM/VDI solutions. > >>> This would enhance the broker function even further and lift the > >>> product above other offerings in the market. That is why I asked to > >>> fix the crippled MMR functionality by supporting Flash 10. > >>> > >>> If Oracle however does not fix the MMR then I need to conclude that > >>> Oracle has already decided to sell Sun Rays only with Virtualbox. > >>> That would limit the broker function of the Sun Ray server which > >>> basically means that the solution will become the same as all other > >>> solutions in the market. > >>> With head to head competition it will than be much harder to build > >>> large volume Sun Ray sales. > >>> > >>> Kind regards, > >>> > >>> Ivar Janmaat > >>> > >>> Craig Bender schreef: > >>>> Folks, > >>>> I apologize if anyone took this to mean we are not pursuing local > >>>> decode solutions, or that I was trying to push Ivar away from wanting > >>>> local decode. That is neither the case, or my intent. > >>>> > >>>> I was simply trying was to highlight that while RCA may be more > >>>> "expensive" in terms of scalability, it has it's place when usability > >>>> is a concern. > >>>> > >>>> At the very least, RCA buys us time to further develop and enhance > >>>> our existing technologies such as direct decode without impacting end > >>>> user experience. > >>>> > >>>> On 9/1/10 10:11 AM, Craig Bender wrote: > >>>>> On paper direct decode looks like a better option, and in some cases > >>>>> it is indeed the better option. Like: > >>>>> > >>>>> A purpose built hardware device, or features in an existing devices > >>>>> chipset, dedicated to video processing. Typically these only support > >>>>> a few formats due to putting codec either in the hardware on in the > >>>>> RTOS. Rarely do the codecs in the device support every possible > >>>>> encoding option, so even video that is "supported" at the higher > >>>>> level of the spec, might not play on device. Codec development takes > >>>>> time, and in many cases the vendors of the purpose built device need > >>>>> to license technology from 3rd parties even though there is a free > >>>>> (to use) Windows > >>>>> codec. The biggest problem with the purpose built device though, is > >>>>> it usually does only one thing. And if it does more than one well it > >>>>> usually costs as much as a PC, but doesn't exactly replace your PC. > >>>>> > >>>>> The other would A device that allows the somewhat easy installation > >>>>> of readily available codecs. Usually this means windows, but > >>>>> definitely means a fat OS. I say somewhat easy installation because > >>>>> things rarely just work. You might get prompted to install a codec, > >>>>> you might have to manually research what codec is needed. There might > >>>>> not be a codec for your OS available, or it might not be free. > >>>>> > >>>>> Then you take thin clients. They have the problems of the purpose > >>>>> built device, with the added the complexity that they really weren't > >>>>> built for > >>>>> video. Sure the chipset may have some codec support (usually parts of > >>>>> a codec that are "free") but not only do you have to write firmware > >>>>> to access the codec and software to stream it down to them, but you > >>>>> have a problem with updates to the video format spec itself. They are > >>>>> constantly changing and you wind up having to either replace the > >>>>> hardware or someone has to start writing software drivers, and > >>>>> eventually you have locked down PC. > >>>>> > >>>>> Just like the Sun Ray "future proofs" the device from desktop (i.e. > >>>>> display almost any desktop on the same device), RCA future proofs the > >>>>> multimedia from the codec required on the display device. > >>>>> > >>>>> It may require more processing at the hypervisor layer, or some cases > >>>>> the Sun Ray Server layer, and it may not be as efficient bandwidth > >>>>> wise as direct decode, but it makes things usable. And at the end of > >>>>> day, it's not usable, it's not worth buying. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The problem with purpose built hardware is that > >>> > >>> _______________________________________________ > >>> SunRay-Users mailing list > >>> [email protected] > >>> http://www.filibeto.org/mailman/listinfo/sunray-users > >> > >> ------------------------------ > >> > >> Message: 4 > >> Date: Thu, 2 Sep 2010 09:53:27 +1000 > >> From: David Bullock<[email protected]> > >> To: SunRay-Users mailing list<[email protected]> > >> Subject: [SunRay-Users] Server Side Graphics Processing (was: Top 3 of > >> new Sun Ray features) > >> Message-ID: > >> <[email protected]> > >> Content-Type: text/plain; charset="iso-8859-1" > >> > >> Craig Bender wrote that decoding video under some scenarios may require: > >> > >> processing at the hypervisor layer, or some cases the Sun Ray Server > >> layer, > >> > >> > >> Just to parade my general ignorance on such things, when the > >> hypervisor/SRS is compositing screen updates (or decoding video) for its > >> myriad clients, is there any benefit from throwing extra graphics > >> cards/GPU's at the server? Or is this not a bottleneck in practice? > >> > >> thanks, > >> David. > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> > >> <http://www.filibeto.org/pipermail/sunray-users/attachments/20100902/e69 > >>b4 b37/attachment-0001.html> > >> > >> ------------------------------ > >> > >> Message: 5 > >> Date: Wed, 01 Sep 2010 17:06:30 -0700 > >> From: Craig Bender<[email protected]> > >> To: SunRay-Users mailing list<[email protected]> > >> Subject: [SunRay-Users] Regarding Flash 10 Content > >> Message-ID:<[email protected]> > >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >> > >> On 9/1/10 3:13 PM, Ivar Janmaat wrote: > >> > The problem with MMR is that it is badly crippled since there is no > >> > Flash 10 content support at this time. > >> > It would be a good idea to put Flash 10 content support in MMR > >> > before Flash 11 arrives. > >> > >> I'm not sure I've covered this before or not, but previous discussions > >> concerning our lack of support for Flash v10 content, or perhaps better > >> stated, the versions of Flash content (v8, v9) that we state support > >> for, may be painting our ability to handle Flash v10 content with a bit > >> too broad of a brush. Perhaps we need state we support Flash v10 > >> content with a footnote based on the following. > >> > >> In short there are two "New modes" that Flash can use to push content to > >> the screen. These are in *addition* to the three that have been > >> available in the past, and are still the most widely used methods. > >> > >> The first is called "Direct" with uses DirectDraw and Direct3D on > >> Windows platforms, and OpenGL on Linux and OSX. > >> > >> The second is called "gpu" and does full fledged compositing using, you > >> guessed it, the gpu on the client. > >> > >> While that does indeed seem like scary stuff, I believe our fear of this > >> feature would seem to be more theoretical than based on reality. > >> > >> Most Flash content developers don't seem to be using it, unless they are > >> developing a solution based around specific hardware, and not for what I > >> would say "normal consumption". Suppose you had a flash front end to > >> your bank. While they may be comfortable to tell you to install Flash, > >> I think the Last thing they would want would be to tell people to update > >> to the latest Direct3D driver or OpenGL. > >> > >> I'm sure there is some direct mode stuff out there, but I still can't > >> find an example of any GPU accelerated Flash content "in the wild". > >> > >> I think most of the issues people are seeing with our Flash solution are > >> because of the size limitation, which is something we are addressing. > >> Granted 1024x768 is a fairly small area, and we've all seen more than > >> our fair share of out of control Flash based sites (http://www.sobe.com/ > >> for instance. > >> > >> More info here on the two new modes from an engineer from Adobe, a bit > >> dated, but explains the features. > >> > >> http://www.kaourantin.net/2008/05/what-does-gpu-acceleration-mean.html > >> > >> Finally, our Flash solution is pretty the same at a higher level as RCA. > >> Both use motion jpeg. We don't have a "Flash" codec in the the Sun Ray, > >> so it's not "MMR", or at least it's not local decode of Flash content. > >> > >> I believe by the time you actually see Direct or GPU mode as a standard > >> or normal way of writing Flash based content (if HTML5 doesn't kill > >> Flash), we should have a solution. > >> > >> > >> > >> > >> ------------------------------ > >> > >> _______________________________________________ > >> SunRay-Users mailing list > >> [email protected] > >> http://www.filibeto.org/mailman/listinfo/sunray-users > >> > >> > >> End of SunRay-Users Digest, Vol 80, Issue 3 > >> ******************************************* > > ------------------------------ > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users > > > End of SunRay-Users Digest, Vol 80, Issue 6 > ******************************************* >
-- ======================================= Alex Brulo Senior Server Engineer (HPC) Information Systems Aston (ISA) Aston University, Aston Triangle, Birmingham, B4 7ET Tel: 0121 204 3673 ISA "Aiming for Excellence in ICT Services" ======================================= Please consider the environment before printing this e-mail ======================================= _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
