- This topic has 164 replies, 21 voices, and was last updated 12 years, 5 months ago by
.
-
Posts
-
grahamlthompson – 12 hours ago »
Rendering HTML ?
Not sure what you mean.
Can you explain ?
What’s not to understand? The GUI is reported to be written in HTML5. That code needs to be “rendered” into a screen presentation, just like your Windows browser renders a website (written in HTML).
Given the speed of presentation of the EPG (in my opinion it’s unacceptably slow)then it’s reasonable to surmise that either the CPU is not efficient at this, or the code is very badly written.
The problem being the CPU is not unlikely since CPUs of all kinds are usually optimised around a specific code set. Equally the code being the problem is not unlikely since HTML5 is very new. Or maybe both?
I believe that the HTML5 support is handled by the inbuilt chipset.
I have not seen any reports that the GUI was written in HTML5, I suppose it could be but why encode something when you don’t need to.
REPASSAC – 3 minutes ago »
I believe that the HTML5 support is handled by the inbuilt chipset.
I have not seen any reports that the GUI was written in HTML5, I suppose it could be but why encode something when you don’t need to.
That statement definitely needs an explanation. How do you believe the GUI is built and presented on the screen? Also, when they “bet the house on HTML5”, what did they mean?
http://www.joinfreesat.co.uk/why-freesat-is-betting-the-house-on-html5/
Encoding something in HTML5 so the same piece of equipment can decode and present it, is a bit of a round-about method but it could have advantages given that the decoding and presentation is done by the chipset.
REPASSAC – 5 minutes ago »
Encoding something in HTML5 so the same piece of equipment can decode and present it, is a bit of a round-about method but it could have advantages given that the decoding and presentation is done by the chipset.
So please answer my question…
“How do you believe the GUI is built and presented on the screen?”
Although I guess it could be the case that this “bit of a round-about method” is the reason why the GUI presentation is so slow?
Given the statement that HTML5 is used, I would suggest that the source is written in C, which constructs a HTML5 page, which it then passed to the chipset to display it.
REPASSAC – 1 hour ago »
Given the statement that HTML5 is used, I would suggest that the source is written in C, which constructs a HTML5 page, which it then passed to the chipset to display it.
OK, we’re in agreement that the GUI is written in HTML5 and then rendered, whether by “chipset” or CPU is a moot point. The use of C I somewhat doubt since HTML5 is in itself a high-level language capable of direct coding for this application. Hence my point that being fairly new it may well have been written inefficiently.
No I did not say it is written in HTML5. It is not a programming language, JavaScript is but has rather a lot of limitations by design.
While I do not know which of these Broadcom products is used some have a lot of features like the BCM7356:
Support for multiple worldwide formats including the DVB-S2, DVB-S and 8PSK standards, with backwards compatibility to the DVB-S standard
High performance and cost effective DDR3-based memory providing significant cost and energy savings over DDR2-based memory
3D graphics engine for an advanced user interface
Dynamic power management controllers that provide a very power efficient ecosystem, capable of shutting down unused system components in real-time
Support for the Digital Living Network Alliance (DLNA®) Interoperability Guidelines to facilitate the easy sharing of digital content between DLNA-enabled devices, allowing a seamless experience for sharing and enjoying digital media and content services throughout the home
Support for the Multimedia Home Platform (MHP), the Adobe Flash® Platform for TV and the RVU Alliance’s pixel accurate Remote User Interface (RUI) technology that allows an identical user experience on multiple devices
A broad array of time-to-market web-based connected home STB software applications environments including Adobe Flash® Platform for TV, Webkit HMTL 5.0, Java, Nokia’s Qt Framework including QtWebkit, DLNA 1.5, and DirectFB application libraries
Unique HD FastRTV™ channel change acceleration technology that improves channel change speeds by up to 500 percent
Support for Energy Star® and European Code of Conduct compliant
Given that direct support is available in some Broadcom chipsets Humax and freesat would have been crazy to try and cook their own HTML5 rendering machine.
REPASSAC – 26 minutes ago »
Given that direct support is available in some Broadcom chipsets Humax and freesat would have been crazy to try and cook their own HTML5 rendering machine.
Eh, did I suggest that? I think not. What is your point in all that techno babble?
I think, based on Freesat’s own press release, that the GUI is written in HTML5 and rendered by some means unknown in the h/w. You meanwhile are just spouting a host of assumptions based on no facts at all.
Pollensa1946 – 10 minutes ago »
REPASSAC – 26 minutes ago »
Given that direct support is available in some Broadcom chipsets Humax and freesat would have been crazy to try and cook their own HTML5 rendering machine.
Eh, did I suggest that? I think not. What is your point in all that techno babble?
I think, based on Freesat’s own press release, that the GUI is written in HTML5 and rendered by some means unknown in the h/w. You meanwhile are just spouting a host of assumptions based on no facts at all.
I was simply giving a example of how HTML5 support is in some Broadcom chipsets that Humax is known to use Broadcom.
“within an HTML5 framework” – You are quoting the Head of Strategy at freesat. Not a technician. No where does he mention “written”.
You assume a lot without knowing what processing is actually being done, for example, in EPG processing.
The “techno babble” as you call it was simply to show you that chipset support does exit for HTML5.
In the link it has this quote…
“And we built our user interface in HTML5”
…seems clear-cut to me. Even although it was written by “Head of Strategy”. Although given the rubbish GUI you might be right, Freesat management have no idea what they’re doing.
I have better things to do, bottle of Cava waiting, so bye.
Pollensa1946 – 36 minutes ago »
In the link it has this quote…
“And we built our user interface in HTML5”
…seems clear-cut to me. Even although it was written by “Head of Strategy”. Although given the rubbish GUI you might be right, Freesat management have no idea what they’re doing.
I have better things to do, bottle of Cava waiting, so bye.
I have better things to do as well – the fine local cotes de Gascoigne.
Have a good evening, enjoy your Cava.
Having followed this thread I am rather puzzled. I would readily agree that the 1000s has some clunky GUI issues, e.g. far to many clicks for simple tasks etc. but up to 3 seconds to paint each new page in the EPG. This is the HDR 1000s we are talking about isn’t it?
The EPG loads almost instantly and scrolls across or down almost as fast as I can press the buttons on the remote. It is every bit as fast as either my old white Sky+ box or my Sky+HD box. It can also switch between tasks as fast as my fingers can hit the buttons.
Faust: pull the other one.
Faust – 1 hour ago »
but up to 3 seconds to paint each new page in the EPG. This is the HDR 1000s we are talking about isn’t it?
Yeah I have to agree with you Faust, 3 seconds is an exaggeration.
Its actually 2.5 seconds between button press and EPG info appearing on screen for each page.
- The topic ‘New software version 1.00.54’ is closed to new replies.