...
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.
| draw.io Diagram |
|---|
|
| Gliffy Diagram |
|---|
| macroId | 9a44e691-f2d6-4e98-97b9-172b5111336d |
|---|
| name | A Traditional approach for rendering.drawio |
|---|
| pagePinrevision | 1 |
|---|
|
Wayland Approach for Rendering
...
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.
| draw.io Diagram |
|---|
|
| Gliffy Diagram |
|---|
| macroId | 681961a5-20a4-4a57-a1c3-f9c3242affbe |
|---|
| name | Wayland approach for rendering.drawio |
|---|
| pagePinrevision | 1 |
|---|
|
Wayland - What and Why?
“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.
| draw.io Diagram |
|---|
| diagramName | wayland.drawio |
|---|
| revision |
|---|
|
| Gliffy Diagram |
|---|
| macroId | b93a2570-86d0-4e43-80ef-cb42656752ff |
|---|
| name | wayland |
|---|
| pagePin | 1 |
|---|
|
Wayland Process flow:
| draw.io Diagram |
|---|
|
| Gliffy Diagram |
|---|
| macroId | f0b7d688-5742-42ef-a444-68b60b513977 |
|---|
| name | wayland process flow.drawio |
|---|
| pagePinrevision | 1 |
|---|
|
Why Westeros?
- Westeros is smalland simple.
- Being small, easier to understand and maintain.
- Caters to needs of embedded systems over traditional desktop computing.
- Shared library that provides an APIfor creating and operating a compositor.
- Use the included sample compositor app OR implement a custom compositor.
- Allows an application to create a Wayland display within itself to create what we call an embedded compositor.
- Main UI can then control application windowandlifecycle.
...
Gives the hosting application (MSO Guide) control over the presentation and composition of 3rd party applications.
| Gliffy Diagramdrawio |
|---|
| diagramName |
|---|
| macroId | efda7236-b23e-4ae7-8cde-ccb657d1636b |
|---|
| name | westeros use case.drawio |
|---|
| pagePinrevision | 1 |
|---|
|
Why WPE
- Newer WebKit= newer features
- WebKit2 w/ Threaded compositor vs. QT single thread WebKit1 architecture.
- New JavaScript Core optimization feature: “Faster Than Light” JIT
- Compared to QTWebkit, WPE is about 30% smaller —around 22 Megabytes.
WPE Architecture
| draw.io Diagram |
|---|
| diagramName | wayland2.drawio |
|---|
| revision | 1 |
|---|
|
| Gliffy Diagram |
|---|
| macroId | 25d6e06b-ec0f-4b1f-aac4-b9548b906b44 |
|---|
| displayName | wayland2 |
|---|
| name | wayland2 |
|---|
| pagePin | 2 |
|---|
|
WPE and Wayland Clients
| Gliffy Diagramdrawio |
|---|
| diagramName |
|---|
| macroId | f9f4f787-a8b9-4c35-a033-a8e3a97b1bce |
|---|
| displayName | Webkit for Wayland architecture.drawio |
|---|
| name | Webkit for Wayland architecture |
|---|
| pagePin | 4 |
|---|
| revision | 1 |
|---|
|
Code Restructure
- Code move:
- Source / WPE —> ThirdParty/ WPE & ThirdParty/ WPE-platform
- Easier up-streaming
- Port acceptance
- Refactor WPE to C back-ends
- New IPC mechanism
| Gliffy Diagramdrawio |
|---|
| diagramName |
|---|
| macroId | 383cafa3-d460-4cd8-8f74-78ff402d67e3 |
|---|
| name | Code restructure.drawio |
|---|
| pagePinrevision | 1 |
|---|
|
Work Accomplished in RDK
...
