Re: [webkit-dev] Announcing WebKit for Wayland
On Tue, Dec 9, 2014 at 1:19 PM, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. The main idea behind this design is to remove the intermediate purpose of the UIProcess when it comes to updating the display server with rendering results from the WebProcess, handling input events (originating from the compositor) in the WebProcess, etc. For such tasks UIProcess did nothing but relay them forward, and not necessarily efficiently. This change in architecture goes hand-in-hand with the idea of removing the dependency on any toolkit. Most of these are nowadays exclusively tailored to run best under some specific desktop environment, relying on additional protocols for window management that bring in unnecessary overhead. And since the toolkit is utilized in the UIProcess, it requires that the UIProcess is run under a compositor, and not in parallel to it. Removing the toolkit also gives us a large amount of leeway in adjusting the input processing, display updates and other things to our needs. But even without the toolkit the whole setup could still easily run under the more traditional environments, as we're recommending for developer setups where the Weston compositor with the WebProcess client runs under the parent X or Wayland display. The current architecture does inhibit sandboxing, and the best alternative solution we can offer at the moment is randomizing the address space layout. We're still open to other possibilities, including perhaps again moving the UIProcess into a separate process but keeping the current design of the WebProcess acting as a direct client of the Wayland compositor. The port has been in the works for four months now, and while we might have not yet approached security seriously, we're definitely not keen on keeping the issues unaddressed. Cheers, Zan Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as
Re: [webkit-dev] Announcing WebKit for Wayland
On Tue, Dec 9, 2014 at 5:52 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Hello, Do you know what are the plans for GTK and EFL? As far as I know, EFL community has tried to support wayland. Thus some folks of WebKit EFL port seem to plan to support the wayland based of EFL support when it is ready. Basically same goes for the GTK+ port -- we mainly rely on the toolkit to properly support the Wayland protocol. Despite that we must deploy a few custom solutions for specific problems. For instance, in order to efficiently transfer the composited results from the WebProcess to the Wayland compositor we are planning to use a nested Wayland compositor in the UIProcess to relay that data to GTK+. First implementations of this approach ended up blitting the rendered data onto the Cairo surface of the relevant GtkWidget. To make things worse, the surface was using shared memory, and had its data invalidated completely whenever the GtkWidget had a redraw queued. This meant that Gyuyoung. On Wednesday, December 10, 2014, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web
Re: [webkit-dev] Announcing WebKit for Wayland
On Wed, Dec 10, 2014 at 9:46 AM, Žan Doberšek zandober...@gmail.com wrote: On Tue, Dec 9, 2014 at 5:52 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Hello, Do you know what are the plans for GTK and EFL? As far as I know, EFL community has tried to support wayland. Thus some folks of WebKit EFL port seem to plan to support the wayland based of EFL support when it is ready. Basically same goes for the GTK+ port -- we mainly rely on the toolkit to properly support the Wayland protocol. Despite that we must deploy a few custom solutions for specific problems. For instance, in order to efficiently transfer the composited results from the WebProcess to the Wayland compositor we are planning to use a nested Wayland compositor in the UIProcess to relay that data to GTK+. First implementations of this approach ended up blitting the rendered data onto the Cairo surface of the relevant GtkWidget. To make things worse, the surface was using shared memory, and had its data invalidated completely whenever the GtkWidget had a redraw queued. This meant that ... a whole lot of data was being sent to the parent compositor for each update of the widget, which obviously caused problems on weaker embedded systems running in 1080p resolution. Luckily in the last few months GTK+ finally received support for drawing OpenGL content in GtkWidgets, so the final implementation will be much more efficient. Cheers, Zan Gyuyoung. On Wednesday, December 10, 2014, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for
[webkit-dev] WKR and webkitbot going offline tonight
Hi, Due to our lab downtime, WKR and webkitbot IRC bots are going down tonight. They should come back up by early tomorrow morning but please let me know if they don't. Meanwhile, you can manually rollout/revert a patch via webkit-patch rollout command, and you can always subscribe to webkit-changes https://lists.webkit.org/mailman/listinfo/webkit-changes list to receive emails for every change made in WebKit. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
