EFL: Scaling From the Embedded World to the Desktop

1Samsung Open Source Group
Cedric Bail
Senior Graphics Developer
Samsung Open Source Group
cedric@osg.samsung.com
EFL: Designing a Vector Graphics API For User Interfaces
Scaling from the embedded world to the desktop !

● EFL, in short !
● Vector graphics for user interfaces
● Designing a modern rendering pipeline for vector graphics
● Questions?

EFL, In Short !

EFL: A Toolkit Created for Enlightenment 17

Enlightenment Foundation Libraries (EFL)
● Spent a decade writing a modern graphic toolkit
● Licensed under a mix of LGPL and BSD license
● Focus on embedded devices, but scale from the low end to the high end.
● First release on January 2011
● Stable, long term API/ABI
● In the process of releasing version 1.16
● 3 month release cycle
● Tizen Native UI Framework

Enlightenment Community
● The Enlightenment community
– 60 unique contributors per release (10 cores)
– 1000 users that build from source
– 2 distributions based on Enlightenment (Bodhi and Elive)
● The Enlightenment community expected Linux to takeoff in the embedded wo
rld, not on the desktop
● The values shared by this community:
● Customizable
● Scalable
● Fast
● Light
● Feature Rich

State of EFL
● Designed for creating a Windows Manager (WM), now used for any type of
application
● Has its own scene graph and rendering library
● Optimized to reduce CPU, GPU, memory and battery usage
● Supports international language requirements (LTR/RTL, UTF8)
● Supports all variations of screens and input devices (scale factor)
● Fully Themable (layout of the application included)
● Supports profiles
● Can take up as little as 8MB of space with a minimal set of dependencies
● Has a modular design

Why We Care About Optimization
● Moore's law doesn't apply to battery life and memory bandwidth
● Most rendering operations are limited directly by memory bandwidth
● Many embedded devices have less available memory than a low end phone
– Refrigerator, oven, dish washer, washing machine, home automation…
● Even a low end phone doesn't have much memory to spare once you run a b
rowser!
● GL context at best consumes 10MB, usually more around 40MB; this is bad
for multitasking!

Current State of Optimization
● Application runtime memory use is mostly driven by screen size
● EFL can fit in 8MB on disk (static compilation with minimal dependencies, OS
included)
● No hard requirement on the GPU
● Enlightenment + Arch Linux combined :
– 48 MB RAM
– 300 Mhz (1024 x 768)
– Yes, for a desktop profile!

Vector Graphics For User Interfaces

Vector Graphics: Quick Definition
Wikipedia :
“Vector graphics are based on vectors (also called paths), which lead
through locations called control points or nodes. Each of these points
has a definite position on the x and y axes of the work plane and determines
the direction of the path; further, each path may be assigned a stroke color,
shape, thinkness, and fill.”

Why Vector Graphics?
● Ease the work of designer and engineer to define animation.
● No interpolation error if frame rate varies.
● Lighter on storage use as you don't need every image
→ Tradeof as they are heavier on CPU usage.
● Not for SCALING ! Everything will scale !
→ No property to discern between readable element and non readable elem
ent.

Let's Look at an Application and Toolkit

Observations
● Common pattern
– Same shape
– Same gradient
– Same color
● Interface are consistent !
● When we raster image, we reuse the same image everywhere
→ Let's do the same with vector graphics !

Designing a Modern Rendering
Pipeline for Vector Graphics

What Should We Cache?
● Cache CPU intensive information
● Minimize amount of memory needed to keep information
● Minimize memory bandwidth needed to replay information
● Vector graphics are done in 3 stages:
– Computing the span lines (CPU intensive)
– Filling that span lines (Depend on operation, but mostly cache bound)
– Compositing the span lines (Memory bound operation)
● Cache the span lines and math, not the generated texture
→ Cache the CPU intensive information without increasing the memory use
● Caching texture result has higher cost during animation

Let's Talk a Little Bit About Modern Devices
● Multi core with different characteristic (big/little)
● Some kind of GPU
● Constrained by memory, because of multi tasking
● Constrained by memory bandwidth
● Constrained by battery
● Everyone expect great and reactive user experience whatever the device
● Everyone want weeks of battery life !

Evas - Scene Graph
● A basic scene graph rendering ascends from the bottom to the top of the tree
● Possible optimizations
– Reorder GL operations to limit Texture and Shader changes
– Partial updates
– Cutout opaque areas
– Complete drawing operations in another thread
– Efficiently cache costly CPU operations between frames
– Deduplicate objects

Now What Can We Do With Vector Graphics in a Scenegraph?
● Possible optimizations :
– Reorder GL operations to limit Texture and Shader changes
– Partial updates
– Cutout opaque areas
– Complete drawing operations in another thread
– Efficiently cache costly CPU operations between frames
– Deduplicate objects
● Vector graphics will always be less efficient than just image rasterizing

Rendering Pipeline – Where We Started
Historical rendering pipeline for Evas

Rendering Pipeline – Where We Are
Current rendering pipeline for Evas

Rendering Pipeline – Where We are Going
Future rendering pipeline for Evas

Ector – Retained Rendering Library
● The idea of retained rendering come from Enesim (http://www.enesim.org)
● Didn't want to reinvent everything, so we have multiple backends:
– Freetype
– Cairo
● Ector is used by Evas for the drawing

Ector – Freetype Backend
● Freetype provides an API to get spans lines easily
● Freetype provides a source code you can include in your project
● It's fast, tested and supports all the primitives we need to generate all shapes
● We can also make it match our retained API
● We already have better performance than expected
● Still missing
– Deduplicating shape
– Asynchronous computation of shape and gradient information
– GL backend

Ector – API
● Surface object per backend with a renderer factory
● Renderer draws one primitive into the surface that created them
● Renderer can be moved at no cost (easy reuse)
● Renderers have 3 functions :
– Prepare
– Render
– Fill
● Renderer :
– Shape
– Gradient Linear
– Gradient Radial

Ector – Where are We Going ?
● Improve testing
● Understand why we have so much difference with Cairo
● Experiment with different GL backend design
– Classic Loop & Blinn Approach
– Use a texture filled with span information to fill
● Vulkan backend once we have some driver to play with
● Replacement of all Evas immediate rendering code by Ector
– Filters
– Text
– Image
– GL

Evas – Integration with the Scene Graph
● Evas works with Evas_Object primitive :
– Rectangle
– Image
– Text
● We just added a Vector graphics object that is handled as a transparent object
● Contain a tree of primitives
● Tree's :
– Can be disconnected from the canvas
– Can be duplicated
– Can be interpolated (following w3c SVG specification)

Evas – What Comes Next ?
● Add SVG file loading/saving support
● Add EET (binary file format for theme) file loading/saving support
● Add more primitive (Likely order) :
– Filter
– Text
– Image

Edje – Theme Integration Proposal
● SVG animation and interaction definition are “tricky”
● Most tool generate heavy animation instead of simpler one
● Keep it simple :
– Starting point defined by SVG
– End point defined by another SVG
– Interpolate in between them
● Vector graphics part
– State defined by a SVG
– Program define rules for interpolation

EFL – Vector Graphics Cheat Sheet
● Vector graphics will always be slower than simple image rendering
● Can still be made fast and usable for real time user interface component
● Requires us to rethink how we handle rendering
● Retained rendering is likely to open a lot of possibility in the future
● EFL introduces 3 new components :
– Ector: Retained rendering library
– Evas_Object_VG: Vector graphics scene graph object
– VECTOR: part in Edje theme

Questions?
Twitter: @SamsungOSG
Slides: http://www.slideshare.net/SamsungOSG

EFL: Scaling From the Embedded World to the Desktop

Related slideshows

More Related Content

EFL: Scaling From the Embedded World to the Desktop

Editor's Notes