Graphics Pipeline and Rendering Technologies
The graphics pipeline is one of the most critical parts of the software stack of any solution with a user interface, and can make or break user interaction. Igalia has years of experience developing and optimizing key components of the Linux graphical pipeline.
Companies developing software for mobile, embedded or desktop environments often find the graphics and rendering software stack to be one of their greatest challenges. The most successful devices and software platforms are known for having a very optimized, friction-free user experience, including fast rendering and fluid touch interfaces.
At Igalia we have been working in this area for the past decade, developing and refining technologies involved in the Linux graphical pipeline ranging from core libraries and components to graphical toolkits and client side web technologies.
We are involved in optimizing the performance of the Linux graphical pipeline of WebKit ports (GTK+, Qt, EFL, wincairo and others). We worked on tasks such as:
- Implementation of new standards such as WebGL and WebAudio, multimedia acceleration and GStreamer integration in WebKit
- Drop-shadows acceleration
- Integration with HarfBuzz for font rendering
- The WebKit2 graphical and multiprocess architectures.
We also have expertise developing and optimizing graphical toolkits for both desktop and embedded software platforms, including years contributing to GTK+, Qt, Hildon, MeegoTouch and Clutter/Cogl.
We can help you ensure that your users have a compelling experience powered by an optimized graphics software stack.
- X System
- Graphical toolkits
- Graphical libraries
- Accelerated Compositing
- Accelerated Rendering
- HTML acceleration
In my previous post I shared that I had managed to get a basic implementation of WebKitGTK+WebKit2 to work under Wayland. I also discussed some of the pieces that were still missing, most important of which was supporting for multiple views, that is,...
Quick Recap In my last post on the subject I explained how during the last WebKitGTK hackfest my colleague Eduardo Lima and I got a working GTK application that made use of the nested compositor design we need in WebKitGTK to get WebKit2 to work under...
So this was my first participation in the WebKitGTK+ hackfest. It was great to have some time to focus on WebKitGTK+ hacking for a few days as well as meeting other colleagues face to face to discuss various related topics, specifically the one I am most...
This post is a brief and quick introduction to Accelerated Compositing and the role this plays in WebKit. The point of accelerated compositing in WebKit is to take advantage of the GPU to accelerate the rendering of web content. To understand how this...
So first things first, check out the video below to see the demo, it showcases Web (Epiphany), the default browser of the GNOME platform, running on WebKit1 under Wayland (Weston) and illustrates: Browsing of regular text/image based sites Embedded HTML5...
If a texture is too large to render to via a framebuffer, then eagerly fail with an error surface.Martin Robinson11/09/2013
Make _cairo_gl_context_bind_framebuffer handle different types of GLES surfaces properly Since, the multisampling setting of a surface never changes in for GLES, so the first thing we do when setting the destination is to ignore the requested...Martin Robinson09/05/2013
Fix more fallout from separating framebuffer binding from setting the destination. In some cases it is sufficient to call glDrawBuffer/glReadBuffer before binding the framebuffer, but the masking-filling-stroking test of cairo-gl-smoke-tests fails if...Martin Robinson06/05/2013
In my previous commit I mistakenly removed the transformation matrix update when cairo_gl_surface_set_size is called. This change restores it.Martin Robinson27/04/2013