Tag / Compositing

  • August 30, 2016 - Mike Blumenkrantz

    Enlightenment Gadget Lifetime Management & Site Creation

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. The previous tutorials covered the basics of gadgets, this article will explore some of the more complex aspects in more detail, specifically lifetime management and gadget site creation. Gadget Lifetime Management Gadgets are bound by two lifetimes: the gadget object’s lifetime, and the gadget instance lifetime. The gadget object is the visible display for a gadget and it is deleted when either the site is deleted, when the gadget instance is deleted, or when the gadget’s orientation changes. This lifetime can be tracked using the EVAS_CALLBACK_DEL callback on the created object. At the time of calling, this indicates that any memory related to the gadget object should be cleaned up, and any non-Elementary sub-objects should be deleted; the toolkit will not delete these automatically and they will leak without manual deletion. Once this […]

    Read More
  • August 23, 2016 - Mike Blumenkrantz

    How Enlightenment Gadgets Handle Sizing

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. This tutorial will provide further detail about aspects of Enlightenment’s new gadget system. Specifically, it will explore how sizing works in different contexts and how simple sizing policies can be leveraged to provide the best view of a gadget. Let’s start with the basics: what is sizing and why does it matter? Gadgets work a bit different than typical application widgets where one would simply pack them into a layout or use WEIGHT and ALIGN hints to fill portions of available regions. A gadget site uses an automatic sizing algorithm to fit itself into its given location. This ensures that gadgets are always the size the user has specified while also maintaining the best sizes for the gadgets so they will look the way the author intended. Finally, it also greatly simplifies the […]

    Read More
  • August 18, 2016 - Mike Blumenkrantz

    An Introduction to Enlightenment Gadget Orientation

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. This tutorial will discuss gadget orientations. Orientation is a core concept that’s vital to understanding how a gadget will be displayed to the user, and it can improve the look of gadgets while also simplifying various parts of the code. In this context, orientation can be thought of as hints the gadget owner provides to the gadget that can be used to provide a more specific view of the gadget, based on it’s location. There are two components to orientation within the gadget system: the orientation enum and the anchor enum. Here is the orientation enum:

    This indicates the axis on which gadgets are positioned. In a horizontal taskbar-style layout E_GADGET_SITE_ORIENT_HORIZONTAL is used, whereas E_GADGET_SITE_ORIENT_VERTICAL would indicate a vertical layout similar to the bar style in Ubuntu’s Unity environment. E_GADGET_SITE_ORIENT_NONE is different; […]

    Read More
  • July 11, 2016 - Mike Blumenkrantz

    How to Create Enlightenment Gadgets

    Creating desktop widgets, aka “gadgets,” has never been easier for Enlightenment enthusiasts than it is after the E21 release. The new E_Gadget system provides an updated API for integrating objects into the compositor, removing most of the overhead from the E_Gadcon system. This makes writing gadgets nearly identical to ordinary application writing. This post will serve as an introduction on the topic of writing gadgets with a focus on the basics; it will use the Start gadget as a reference. How to Create a Gadget The first step to integrating a new gadget is to add the new gadget type to the subsystem so the user can access it. This is done with the following function:

    This function coincides with related callbacks:

    Using e_gadget_type_add, a developer can implement gadgets of type, calling callback to create the gadget object, and optionally providing wizard callback to run configuration options for […]

    Read More
  • June 10, 2016 - Mike Blumenkrantz and Derek Foreman

    Upcoming Enlightenment Improvements: DMABuf & Teamwork V2

    E21 has been under heavy development since December of last year; the primary goals for have been to provide a more rapid release and expedite improvements in Wayland compositing to provide a much more usable experience. With the release pending, here’s a roundup of a couple recently-added Wayland features that are coming in this release. Improving Memory Sharing for Video Processing with DMABuf DMABuf is an infrastructure for sharing memory between various pieces of hardware. It’s a key technology to enable a high performance video pipeline without wasted memory copies, but its benefits aren’t limited to video processing and playback. EFL and Enlightenment now both support the Wayland DMABuf protocol, allowing clients to create buffers that can be dropped into a hardware video plane or used as a texture by the GPU, without the inherent memory copy required for wl_shm buffers. While this is good news for video players, we’ve […]

    Read More
  • Fill buffer. Attach buffer to surface. Damage surface. Commit surface. Ok, now you’ve got a picture on screen, that was easy, right? This is the (somewhat simplified) sequence of requests that’s required to show an image on screen with Wayland. A buffer is what your client draws into. A surface is what the compositor displays your buffer on. The commit operation tells the compositor it’s time to atomically perform all the surface operations you’ve been sending it.  Any surface requests prior to the commit have been buffered, and could have been requested in any order (the compositor performs them in the appropriate order during the commit). How Wayland Uses Damage to Redraw Surfaces Damage is today’s area of focus: it’s how you tell the compositor where the surface has changed since the last time it was committed. While rendering into its buffer, the client should create a list of rectangles […]

    Read More
  • May 6, 2016 - Mike Blumenkrantz

    Wayland Recovery: A Journey Of Discovery

    Wayland on the desktop is a constantly evolving project. Whether it’s improvements to the drag-n-drop protocol or extreme functionality enhancements in the client-side decorations, Wayland is a fast-moving target which allows developers to shape it in almost any way they desire. However, there are some limitations to a Wayland compositor when compared to X11 window managers. Under X11, a window manager is just a client of the XServer; this allows it to do things like restart itself without killing the user’s session. In Wayland, a restart of the running session’s compositor disconnects all the active clients, causing them to terminate. This increases the difficulty of things like crash handling where the environment can gracefully restart itself if there’s a crash. How to Crash Gracefully This is where a newly-created extension comes into play: the Session Recovery Extension. With Session Recovery enabled, a client is able to reconnect to the compositor […]

    Read More
  • April 1, 2016 - Mike Blumenkrantz and Derek Foreman

    CSS: Revolutionizing the Appearance of the WWW

    One of the most notable and enduring Linux desktop paradigms has been desktop effects: the coupling of various desktop environments with graphical niceties, also known as “eye candy.” With the advent of the XComposite extension in the mid 2000s, mainstream eye candy was taken to new levels through a small project called Compiz which used the texture from pixmap extension to apply hardware-accelerated effects to windows on the fly. From Compiz came the effect that is known throughout the Linux world as “wobbly windows” or, for many developers, “that feature we aren’t implementing.” By applying OpenGL vertex transforms to the textures created using the previously-mentioned extension, windows would appear to deform when moved and resized. This has persisted in being the benchmark for all graphical desktop effects for a decade, and numbers may not go high enough to enumerate all the users who have asked for this effect in Enlightenment […]

    Read More
  • January 8, 2016 - Mike Blumenkrantz

    Desktop Compositing: How Much Overdraw Is Too Much?

    In my previous post on compositing, I covered the overall methodology with which I implemented Compiz plugin support in the Enlightenment compositor. Now I’m going to go into some detail about the rendering portion. The first thing that should be reiterated is Compiz only performs damage calculations for the entire screen and does not track them per-window. This is, to say the least, problematic. There’s no way to easily predict where a window will draw at any given time either: there are window effects that cause clients to zoom in/out to/from the mouse cursor, and others that cause the client to bounce around outside of its frame region. The compositor must be prepared to draw things for each window at any geometry on the screen at any time, regardless of common sense clipping. Rendering Outside the Box The first attempt I made at getting things to work was to just […]

    Read More
  • December 11, 2015 - Mike Blumenkrantz

    Manual Compositing with Compiz and Enlightenment

    This is the first article in a two part series on compositing with Compiz and Enlightenment. I recently implemented  a proof of concept for Compiz effect modules in the Enlightenment compositor. In this article, I will explore the methodology behind the implementation and cover some of the AWESOME hacks that made it possible. Replacing Default Compositor Behaviors with Compiz To start, let’s examine how Compiz operates. There is an OpenGL extension that allows an X11 pixmap to be bound to a texture. Compiz operates based on the principle that the compositor can render this texture in any way, at any time, and the underlying X11 input window will be moved quietly to wherever the rendered content ends up. This creates the illusion that the entire window (input and output) is moving in an irregular manner, when in reality, the window’s output is moving around and the window’s input region is […]

    Read More