On 2/28/2012 11:27 AM, Glenn Adams wrote: > > On Tue, Feb 28, 2012 at 12:10 PM, Charles Pritchard <chuck@jumis.com > <mailto:chuck@jumis.com>> wrote: > > The issue has been with JS implementations, not hardware. > > > I beg to differ. In the case of TVs (as oposed to STBs or HPs), the > amount of RAM and CPU capacities available for JS implementations are > significantly less (sometimes orders of magnitude). The traditional > focus on absolute minimization of BoM (bill of materials) cost > continues to produce a performance barrier for most TVs. Sure, more > capacity could be added until it becomes merely a JS/VM implementation > issue, but that has not happened in general in this device class. Give me some numbers, and I'll do what I can to benchmark. If you're strictly talking about hardware based implementations, then yes, it ought to be something like a JS crypto API, as Tab brought up. If it's a "smart TV" with a JS engine on it, then it ought to have enough power to grab an ArrayBuffer via XHR and push it into the media element, otherwise, it just doesn't have enough juice to run what the web considers HTML5. If this is about making the Nintendo Wii+opera the baseline of performance, we can do that. I need something tangible to work with. I realize that my mobile phone is more powerful than the devices of yesteryear, and perhaps, some of the devices coming out next year. -CharlesReceived on Tuesday, 28 February 2012 19:35:13 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC