Wayland – What and Why?<\/h2>\n\n\n\n- Primarily a protocol for compositionof different surfaces\/layers.<\/li>\n
- compositor + display server + window manager.<\/li>\n
- Uses EGLto avoid OS specific windowing functionality.<\/li>\n
- Started as a replacement for the X Windowing System (X11).<\/li>\n
- Unlike X has no rendering API.<\/li>\n
- Its implementations are lightweightwith a small footprint<\/li>\n
- Wayland is primarily focused on performance, code maintainability and security<\/li>\n<\/ul>\n\n\n
Webkit<\/span> for Wayland<\/span><\/h2>\n\n\n\n- Wayland provides <\/span>simple, elegant, <\/span>graphics compositing <\/span>integration between <\/span>different layers <\/span>using EGL (interface between <\/span>Khronos<\/span> rendering <\/span>APIs<\/span>)<\/span><\/li>\n
- Wayland started as <\/span>a replacement <\/span>for the X Windowing <\/span>System (<\/span>X11<\/span>).<\/span><\/li>\n
- Wayland is not an implementation <\/span>but a <\/span>protocol specification between a <\/span>display server <\/span>and its <\/span>clients<\/span><\/li>\n
- Its implementations <\/span>are lightweight <\/span>with a small <\/span>footprint<\/span><\/li>\n
- Wayland is <\/span>primarily focused on performance, <\/span>code maintainability <\/span>and security<\/span><\/li>\n<\/ul>\n\n\n
Advantage of WPE over <\/span>QtWebKit<\/span><\/span><\/h2>\n\n\n<\/p>\nNewer WebKit= newer features:<\/strong><\/p>\n<\/p>\n\n- Contributions in the “upstream” direction are also important to the growth of the RDK, to attract more development and grow the community.<\/li>\n
- It’s much faster then QT.<\/li>\n
- For Gstreamer, we contributed a way to expose the video fragments, e.g. MPEG DASH smooth streaming, from the browser using Media Source Extensions (MSEs).<\/li>\n<\/ul>\n
Faster:<\/strong><\/p>\n<\/p>\n\n- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.\n
\n- UI Process, Web Process, Network Process and Database Process<\/li>\n<\/ul>\n<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- JSC inline with modern day HTML5 development (e.g. better JIT support for closures)<\/li>\n<\/ul>\n
Smaller:<\/strong><\/p>\n<\/p>\n\n- Compared to QTWebkit, WPE is about 30% smaller — around 22 Megabytes,<\/li>\n
- On average, compared to 32 Megabytes while packing 60% more features<\/li>\n<\/ul>\n\n\n
A Traditional Approach for Rendering<\/span><\/h2>\n\n\nIn traditional approach, the central role of X-Server and the steps required to get contents on to the screen is presented in below diagram.
<\/span><\/p>\n<\/p>\n![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/A%20Traditional%20approach%20for%20rendering.drawio.png\")
<\/p>\n\n\n
Wayland Approach for Rendering<\/span><\/h2>\n\n\n<\/p>\nRemoved X-Server and the compositor is the display server. Lets the compositor send the input event directly to the client and lets the client sent the damage event directly to the compositor.<\/p>\n<\/p>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/Wayland%20approach%20for%20rendering.drawio.png\")
<\/p>\n\n\n
Wayland – What and Why?<\/h2>\n\n\n
“Wayland is a protocol for a compositor to talk to its client as well as a C lib implementation of that protocol”. Weston is the reference implementation for wayland. Westeros is a compositor, a replacement of Weston. This provides clear interface towards graphics and input.<\/p>\n<\/p>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/wayland.drawio.png\")
<\/p>\n
Wayland Process flow:<\/strong><\/p>\n<\/p>\n![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/wayland%20process%20flow.drawio.png\")
<\/p>\n\n\n
Why Westeros?<\/h2>\n\n\n\n- Westeros is smalland simple.<\/li>\n
- Being small, easier to understand and maintain.<\/li>\n
- Caters to needs of embedded systems over traditional desktop computing.<\/li>\n
- Shared library that provides an APIfor creating and operating a compositor.<\/li>\n
- Use the included sample compositor app OR implement a custom compositor.<\/li>\n
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.<\/li>\n
- Main UI can then control application windowandlifecycle.<\/li>\n<\/ul>\n\n\n
Westeros Use Case<\/h2>\n\n\n
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.<\/p>\n<\/p>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/westeros%20use%20case.drawio.png\")
<\/p>\n\n\n
Why WPE<\/h2>\n\n\n\n- Newer WebKit= newer features<\/li>\n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.<\/li>\n<\/ul>\n\n\n
WPE Architecture<\/h2>\n\n\n<\/p>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/wayland2.drawio.png\")
<\/p>\n\n\n
WPE and Wayland Clients<\/h2>\n\n\n<\/p>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/Webkit%20for%20Wayland%20architecture.drawio.png\")
<\/p>\n\n\n
Code Restructure <\/h2>\n\n\n\n- Code move:<\/li>\n
- Source \/ WPE —> ThirdParty\/ WPE & ThirdParty\/ WPE-platform<\/li>\n
- Easier up-streaming<\/li>\n
- Port acceptance<\/li>\n
- Refactor WPE to C back-ends<\/li>\n
- New IPC mechanism<\/li>\n<\/ul>\n
![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/Code%20restructure.drawio.png\")
<\/p>\n\n\n
Work Accomplished in RDK<\/h2>\n\n\n\n- Ported on RPI<\/li>\n
- MIPS support for BCM targets<\/li>\n
- Addition of Intel-CE and other BCM configurations<\/li>\n
- MSE and EME implementation for YouTube leanback<\/li>\n
- Parity or better than QtWebKit.<\/li>\n
- Shadow Dom<\/span><\/li>\n
- Wayland Support<\/span><\/li>\n
- Fullscreen<\/span> API<\/span><\/li>\n
- MIPS JIT Architecture Change<\/span><\/li>\n
- Walyland<\/span> Reference Backend<\/span><\/li>\n
- Speech APIs & reference implementation<\/li>\n
- Geolocation<\/span><\/li>\n
- Notifications<\/span><\/li>\n
- PlayReady DRM<\/span><\/li>\n
- Automated test runner<\/span><\/li>\n
- IndexdDB<\/span> Support<\/span><\/li>\n
- Injected Bundles<\/li>\n
- Full MSE Compliance<\/li>\n
- WebCrypto<\/span><\/li>\n
- View <\/span>Backends<\/span> for non-Wayland<\/span><\/li>\n
- Gamepad Support<\/span><\/li>\n<\/ul>\n\n\n
Functional Test (HTML5): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span> <\/span>https:\/\/html5test.com\/<\/a><\/span><\/p>\n![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/image2017-10-31_12-3-52.png\")
<\/span>
<\/span><\/p>\n\n\nFunctional Test(CSS3): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span>http:\/\/css3test.com\/<\/a><\/span><\/p>\n![](\"\/wp-content\/uploads\/sites\/16\/2023\/09\/image2017-10-31_12-6-10.png\")
<\/span><\/span><\/p>\n\n\nRepositories<\/span><\/h2>\n\n\n<\/p>\n\n- WPE: https:\/\/github.com\/Metrological\/WebKitForWayland<\/a><\/li>\n
- OE recipe: https:\/\/github.com\/Metrological\/meta-metrological<\/a><\/li>\n
- Buildroot: https:\/\/<\/a>github.com\/Metrological\/buildroot-wpe<\/a><\/li>\n<\/ul>\n\n\n
WPE Support with RDK – Recipes<\/span><\/h2>\n\n\n<\/p>\nWeston:<\/strong><\/p>\n
Webkit<\/span> for Wayland<\/span><\/h2>\n\n\n\n- Wayland provides <\/span>simple, elegant, <\/span>graphics compositing <\/span>integration between <\/span>different layers <\/span>using EGL (interface between <\/span>Khronos<\/span> rendering <\/span>APIs<\/span>)<\/span><\/li>\n
- Wayland started as <\/span>a replacement <\/span>for the X Windowing <\/span>System (<\/span>X11<\/span>).<\/span><\/li>\n
- Wayland is not an implementation <\/span>but a <\/span>protocol specification between a <\/span>display server <\/span>and its <\/span>clients<\/span><\/li>\n
- Its implementations <\/span>are lightweight <\/span>with a small <\/span>footprint<\/span><\/li>\n
- Wayland is <\/span>primarily focused on performance, <\/span>code maintainability <\/span>and security<\/span><\/li>\n<\/ul>\n\n\n
Advantage of WPE over <\/span>QtWebKit<\/span><\/span><\/h2>\n\n\n<\/p>\nNewer WebKit= newer features:<\/strong><\/p>\n<\/p>\n\n- Contributions in the “upstream” direction are also important to the growth of the RDK, to attract more development and grow the community.<\/li>\n
- It’s much faster then QT.<\/li>\n
- For Gstreamer, we contributed a way to expose the video fragments, e.g. MPEG DASH smooth streaming, from the browser using Media Source Extensions (MSEs).<\/li>\n<\/ul>\n
Faster:<\/strong><\/p>\n<\/p>\n\n- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.\n
\n- UI Process, Web Process, Network Process and Database Process<\/li>\n<\/ul>\n<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- JSC inline with modern day HTML5 development (e.g. better JIT support for closures)<\/li>\n<\/ul>\n
Smaller:<\/strong><\/p>\n<\/p>\n\n- Compared to QTWebkit, WPE is about 30% smaller — around 22 Megabytes,<\/li>\n
- On average, compared to 32 Megabytes while packing 60% more features<\/li>\n<\/ul>\n\n\n
A Traditional Approach for Rendering<\/span><\/h2>\n\n\nIn traditional approach, the central role of X-Server and the steps required to get contents on to the screen is presented in below diagram.
<\/span><\/p>\n<\/p>\n<\/p>\n\n\n
Wayland Approach for Rendering<\/span><\/h2>\n\n\n<\/p>\nRemoved X-Server and the compositor is the display server. Lets the compositor send the input event directly to the client and lets the client sent the damage event directly to the compositor.<\/p>\n<\/p>\n
<\/p>\n\n\n
Wayland – What and Why?<\/h2>\n\n\n
“Wayland is a protocol for a compositor to talk to its client as well as a C lib implementation of that protocol”. Weston is the reference implementation for wayland. Westeros is a compositor, a replacement of Weston. This provides clear interface towards graphics and input.<\/p>\n<\/p>\n
<\/p>\n
Wayland Process flow:<\/strong><\/p>\n<\/p>\n<\/p>\n\n\n
Why Westeros?<\/h2>\n\n\n\n- Westeros is smalland simple.<\/li>\n
- Being small, easier to understand and maintain.<\/li>\n
- Caters to needs of embedded systems over traditional desktop computing.<\/li>\n
- Shared library that provides an APIfor creating and operating a compositor.<\/li>\n
- Use the included sample compositor app OR implement a custom compositor.<\/li>\n
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.<\/li>\n
- Main UI can then control application windowandlifecycle.<\/li>\n<\/ul>\n\n\n
Westeros Use Case<\/h2>\n\n\n
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.<\/p>\n<\/p>\n
<\/p>\n\n\n
Why WPE<\/h2>\n\n\n\n- Newer WebKit= newer features<\/li>\n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.<\/li>\n<\/ul>\n\n\n
WPE Architecture<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\n
WPE and Wayland Clients<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\n
Code Restructure <\/h2>\n\n\n\n- Code move:<\/li>\n
- Source \/ WPE —> ThirdParty\/ WPE & ThirdParty\/ WPE-platform<\/li>\n
- Easier up-streaming<\/li>\n
- Port acceptance<\/li>\n
- Refactor WPE to C back-ends<\/li>\n
- New IPC mechanism<\/li>\n<\/ul>\n
<\/p>\n\n\n
Work Accomplished in RDK<\/h2>\n\n\n\n- Ported on RPI<\/li>\n
- MIPS support for BCM targets<\/li>\n
- Addition of Intel-CE and other BCM configurations<\/li>\n
- MSE and EME implementation for YouTube leanback<\/li>\n
- Parity or better than QtWebKit.<\/li>\n
- Shadow Dom<\/span><\/li>\n
- Wayland Support<\/span><\/li>\n
- Fullscreen<\/span> API<\/span><\/li>\n
- MIPS JIT Architecture Change<\/span><\/li>\n
- Walyland<\/span> Reference Backend<\/span><\/li>\n
- Speech APIs & reference implementation<\/li>\n
- Geolocation<\/span><\/li>\n
- Notifications<\/span><\/li>\n
- PlayReady DRM<\/span><\/li>\n
- Automated test runner<\/span><\/li>\n
- IndexdDB<\/span> Support<\/span><\/li>\n
- Injected Bundles<\/li>\n
- Full MSE Compliance<\/li>\n
- WebCrypto<\/span><\/li>\n
- View <\/span>Backends<\/span> for non-Wayland<\/span><\/li>\n
- Gamepad Support<\/span><\/li>\n<\/ul>\n\n\n
Functional Test (HTML5): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span> <\/span>https:\/\/html5test.com\/<\/a><\/span><\/p>\n<\/span>
<\/span><\/p>\n\n\nFunctional Test(CSS3): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span>http:\/\/css3test.com\/<\/a><\/span><\/p>\n<\/span><\/span><\/p>\n\n\nRepositories<\/span><\/h2>\n\n\n<\/p>\n\n- WPE: https:\/\/github.com\/Metrological\/WebKitForWayland<\/a><\/li>\n
- OE recipe: https:\/\/github.com\/Metrological\/meta-metrological<\/a><\/li>\n
- Buildroot: https:\/\/<\/a>github.com\/Metrological\/buildroot-wpe<\/a><\/li>\n<\/ul>\n\n\n
WPE Support with RDK – Recipes<\/span><\/h2>\n\n\n<\/p>\nWeston:<\/strong><\/p>\n
Advantage of WPE over <\/span>QtWebKit<\/span><\/span><\/h2>\n\n\n<\/p>\nNewer WebKit= newer features:<\/strong><\/p>\n<\/p>\n\n- Contributions in the “upstream” direction are also important to the growth of the RDK, to attract more development and grow the community.<\/li>\n
- It’s much faster then QT.<\/li>\n
- For Gstreamer, we contributed a way to expose the video fragments, e.g. MPEG DASH smooth streaming, from the browser using Media Source Extensions (MSEs).<\/li>\n<\/ul>\n
Faster:<\/strong><\/p>\n<\/p>\n\n- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.\n
\n- UI Process, Web Process, Network Process and Database Process<\/li>\n<\/ul>\n<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- JSC inline with modern day HTML5 development (e.g. better JIT support for closures)<\/li>\n<\/ul>\n
Smaller:<\/strong><\/p>\n<\/p>\n\n- Compared to QTWebkit, WPE is about 30% smaller — around 22 Megabytes,<\/li>\n
- On average, compared to 32 Megabytes while packing 60% more features<\/li>\n<\/ul>\n\n\n
A Traditional Approach for Rendering<\/span><\/h2>\n\n\nIn traditional approach, the central role of X-Server and the steps required to get contents on to the screen is presented in below diagram.
<\/span><\/p>\n<\/p>\n<\/p>\n\n\n
Wayland Approach for Rendering<\/span><\/h2>\n\n\n<\/p>\nRemoved X-Server and the compositor is the display server. Lets the compositor send the input event directly to the client and lets the client sent the damage event directly to the compositor.<\/p>\n<\/p>\n
<\/p>\n\n\n
Wayland – What and Why?<\/h2>\n\n\n
“Wayland is a protocol for a compositor to talk to its client as well as a C lib implementation of that protocol”. Weston is the reference implementation for wayland. Westeros is a compositor, a replacement of Weston. This provides clear interface towards graphics and input.<\/p>\n<\/p>\n
<\/p>\n
Wayland Process flow:<\/strong><\/p>\n<\/p>\n<\/p>\n\n\n
Why Westeros?<\/h2>\n\n\n\n- Westeros is smalland simple.<\/li>\n
- Being small, easier to understand and maintain.<\/li>\n
- Caters to needs of embedded systems over traditional desktop computing.<\/li>\n
- Shared library that provides an APIfor creating and operating a compositor.<\/li>\n
- Use the included sample compositor app OR implement a custom compositor.<\/li>\n
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.<\/li>\n
- Main UI can then control application windowandlifecycle.<\/li>\n<\/ul>\n\n\n
Westeros Use Case<\/h2>\n\n\n
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.<\/p>\n<\/p>\n
<\/p>\n\n\n
Why WPE<\/h2>\n\n\n\n- Newer WebKit= newer features<\/li>\n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.<\/li>\n<\/ul>\n\n\n
WPE Architecture<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\n
WPE and Wayland Clients<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\n
Code Restructure <\/h2>\n\n\n\n- Code move:<\/li>\n
- Source \/ WPE —> ThirdParty\/ WPE & ThirdParty\/ WPE-platform<\/li>\n
- Easier up-streaming<\/li>\n
- Port acceptance<\/li>\n
- Refactor WPE to C back-ends<\/li>\n
- New IPC mechanism<\/li>\n<\/ul>\n
<\/p>\n\n\n
Work Accomplished in RDK<\/h2>\n\n\n\n- Ported on RPI<\/li>\n
- MIPS support for BCM targets<\/li>\n
- Addition of Intel-CE and other BCM configurations<\/li>\n
- MSE and EME implementation for YouTube leanback<\/li>\n
- Parity or better than QtWebKit.<\/li>\n
- Shadow Dom<\/span><\/li>\n
- Wayland Support<\/span><\/li>\n
- Fullscreen<\/span> API<\/span><\/li>\n
- MIPS JIT Architecture Change<\/span><\/li>\n
- Walyland<\/span> Reference Backend<\/span><\/li>\n
- Speech APIs & reference implementation<\/li>\n
- Geolocation<\/span><\/li>\n
- Notifications<\/span><\/li>\n
- PlayReady DRM<\/span><\/li>\n
- Automated test runner<\/span><\/li>\n
- IndexdDB<\/span> Support<\/span><\/li>\n
- Injected Bundles<\/li>\n
- Full MSE Compliance<\/li>\n
- WebCrypto<\/span><\/li>\n
- View <\/span>Backends<\/span> for non-Wayland<\/span><\/li>\n
- Gamepad Support<\/span><\/li>\n<\/ul>\n\n\n
Functional Test (HTML5): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span> <\/span>https:\/\/html5test.com\/<\/a><\/span><\/p>\n<\/span>
<\/span><\/p>\n\n\nFunctional Test(CSS3): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span>http:\/\/css3test.com\/<\/a><\/span><\/p>\n<\/span><\/span><\/p>\n\n\nRepositories<\/span><\/h2>\n\n\n<\/p>\n\n- WPE: https:\/\/github.com\/Metrological\/WebKitForWayland<\/a><\/li>\n
- OE recipe: https:\/\/github.com\/Metrological\/meta-metrological<\/a><\/li>\n
- Buildroot: https:\/\/<\/a>github.com\/Metrological\/buildroot-wpe<\/a><\/li>\n<\/ul>\n\n\n
WPE Support with RDK – Recipes<\/span><\/h2>\n\n\n<\/p>\nWeston:<\/strong><\/p>\n
- \n
- Contributions in the “upstream” direction are also important to the growth of the RDK, to attract more development and grow the community.<\/li>\n
- It’s much faster then QT.<\/li>\n
- For Gstreamer, we contributed a way to expose the video fragments, e.g. MPEG DASH smooth streaming, from the browser using Media Source Extensions (MSEs).<\/li>\n<\/ul>\n
Faster:<\/strong><\/p>\n<\/p>\n
- \n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.\n
- \n
- UI Process, Web Process, Network Process and Database Process<\/li>\n<\/ul>\n<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- JSC inline with modern day HTML5 development (e.g. better JIT support for closures)<\/li>\n<\/ul>\n
Smaller:<\/strong><\/p>\n<\/p>\n
- \n
- Compared to QTWebkit, WPE is about 30% smaller — around 22 Megabytes,<\/li>\n
- On average, compared to 32 Megabytes while packing 60% more features<\/li>\n<\/ul>\n\n\n
A Traditional Approach for Rendering<\/span><\/h2>\n\n\n
In traditional approach, the central role of X-Server and the steps required to get contents on to the screen is presented in below diagram.
<\/span><\/p>\n<\/p>\n<\/p>\n\n\nWayland Approach for Rendering<\/span><\/h2>\n\n\n<\/p>\n
Removed X-Server and the compositor is the display server. Lets the compositor send the input event directly to the client and lets the client sent the damage event directly to the compositor.<\/p>\n<\/p>\n
<\/p>\n\n\nWayland – What and Why?<\/h2>\n\n\n
“Wayland is a protocol for a compositor to talk to its client as well as a C lib implementation of that protocol”. Weston is the reference implementation for wayland. Westeros is a compositor, a replacement of Weston. This provides clear interface towards graphics and input.<\/p>\n<\/p>\n
<\/p>\nWayland Process flow:<\/strong><\/p>\n<\/p>\n
<\/p>\n\n\nWhy Westeros?<\/h2>\n\n\n
- \n
- Westeros is smalland simple.<\/li>\n
- Being small, easier to understand and maintain.<\/li>\n
- Caters to needs of embedded systems over traditional desktop computing.<\/li>\n
- Shared library that provides an APIfor creating and operating a compositor.<\/li>\n
- Use the included sample compositor app OR implement a custom compositor.<\/li>\n
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.<\/li>\n
- Main UI can then control application windowandlifecycle.<\/li>\n<\/ul>\n\n\n
Westeros Use Case<\/h2>\n\n\n
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.<\/p>\n<\/p>\n
<\/p>\n\n\nWhy WPE<\/h2>\n\n\n
- \n
- Newer WebKit= newer features<\/li>\n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.<\/li>\n
- New JavaScript Core optimization feature: “Faster Than Light” JIT<\/li>\n
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.<\/li>\n<\/ul>\n\n\n
WPE Architecture<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\nWPE and Wayland Clients<\/h2>\n\n\n<\/p>\n
<\/p>\n\n\nCode Restructure <\/h2>\n\n\n
- \n
- Code move:<\/li>\n
- Source \/ WPE —> ThirdParty\/ WPE & ThirdParty\/ WPE-platform<\/li>\n
- Easier up-streaming<\/li>\n
- Port acceptance<\/li>\n
- Refactor WPE to C back-ends<\/li>\n
- New IPC mechanism<\/li>\n<\/ul>\n<\/p>\n\n\n
Work Accomplished in RDK<\/h2>\n\n\n
- \n
- Ported on RPI<\/li>\n
- MIPS support for BCM targets<\/li>\n
- Addition of Intel-CE and other BCM configurations<\/li>\n
- MSE and EME implementation for YouTube leanback<\/li>\n
- Parity or better than QtWebKit.<\/li>\n
- Shadow Dom<\/span><\/li>\n
- Wayland Support<\/span><\/li>\n
- Fullscreen<\/span> API<\/span><\/li>\n
- MIPS JIT Architecture Change<\/span><\/li>\n
- Walyland<\/span> Reference Backend<\/span><\/li>\n
- Speech APIs & reference implementation<\/li>\n
- Geolocation<\/span><\/li>\n
- Notifications<\/span><\/li>\n
- PlayReady DRM<\/span><\/li>\n
- Automated test runner<\/span><\/li>\n
- IndexdDB<\/span> Support<\/span><\/li>\n
- Injected Bundles<\/li>\n
- Full MSE Compliance<\/li>\n
- WebCrypto<\/span><\/li>\n
- View <\/span>Backends<\/span> for non-Wayland<\/span><\/li>\n
- Gamepad Support<\/span><\/li>\n<\/ul>\n\n\n
Functional Test (HTML5): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span> <\/span>https:\/\/html5test.com\/<\/a><\/span><\/p>\n
<\/span>
<\/span><\/p>\n\n\nFunctional Test(CSS3): QTWebkit Vs WPEWebKit<\/h2>\n\n\n
These tests are based on the site <\/span>http:\/\/css3test.com\/<\/a><\/span><\/p>\n
<\/span><\/span><\/p>\n\n\nRepositories<\/span><\/h2>\n\n\n<\/p>\n
- \n
- WPE: https:\/\/github.com\/Metrological\/WebKitForWayland<\/a><\/li>\n
- OE recipe: https:\/\/github.com\/Metrological\/meta-metrological<\/a><\/li>\n
- Buildroot: https:\/\/<\/a>github.com\/Metrological\/buildroot-wpe<\/a><\/li>\n<\/ul>\n\n\n
WPE Support with RDK – Recipes<\/span><\/h2>\n\n\n<\/p>\n
Weston:<\/strong><\/p>\n
- OE recipe: https:\/\/github.com\/Metrological\/meta-metrological<\/a><\/li>\n
- Wayland Support<\/span><\/li>\n
- WebKit2 w\/ Threaded compositor vs. QT single thread WebKit1 architecture.\n