My Humax Forum

• Home
• LOGIN
• Register
• Search
on Amazon

My Humax Forum » Freesat HD » HDR 1000, 1010, 1100S

61. 

    Pollensa1946
    

    special member
    Joined: Sep '12
    Posts: 1,171

    offline

    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?

    | Sat 29 Jun 2013 10:15:45 #61 |
62. 

    REPASSAC
    

    special member
    Joined: Mar '11
    Posts: 4,100

    offline

    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.

    | Sat 29 Jun 2013 11:43:10 #62 |
63. 

    Pollensa1946
    

    special member
    Joined: Sep '12
    Posts: 1,171

    offline

    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/

    | Sat 29 Jun 2013 11:48:04 #63 |
64. 

    REPASSAC
    

    special member
    Joined: Mar '11
    Posts: 4,100

    offline

    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.

    | Sat 29 Jun 2013 12:01:48 #64 |
65. 

    Pollensa1946
    

    special member
    Joined: Sep '12
    Posts: 1,171

    offline

    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?

    | Sat 29 Jun 2013 12:13:21 #65 |
66. 

    REPASSAC
    

    special member
    Joined: Mar '11
    Posts: 4,100

    offline

    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.

    | Sat 29 Jun 2013 13:12:02 #66 |
67. 

    Pollensa1946
    

    special member
    Joined: Sep '12
    Posts: 1,171

    offline

    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.

    | Sat 29 Jun 2013 14:46:42 #67 |
68. 

    REPASSAC
    

    special member
    Joined: Mar '11
    Posts: 4,100

    offline

    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.

    | Sat 29 Jun 2013 15:25:19 #68 |
69. 

    Pollensa1946
    

    special member
    Joined: Sep '12
    Posts: 1,171

    offline

    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.

    | Sat 29 Jun 2013 15:56:18 #69 |
70. 

    REPASSAC
    

    special member
    Joined: Mar '11
    Posts: 4,100

    offline

    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.

    | Sat 29 Jun 2013 16:20:21 #70 |

RSS feed for this topic

Topic Closed

This topic has been closed to new replies.