#Athens vector graphics API
Introduction
Athens is a new graphics API, currently under development.
The main design goals of new API is following:
- provide a clean and simple interface for rendering vector graphics
- layered implementation: common front-end, various backends (Cairo, OpenGL, Balloon etc)
- in a future, serve as a main graphics engine for Pharo
Surfaces
A surface represents a media, where all drawing operations will be realized. Surface connects a library front-end with concrete low-level rendering backend, and should support creating and operating with following objects:
- canvas
- shapes (paths)
- paints (colors, gradients etc)
- transformation matrices (coordinate system)
- bitmaps
The way, how these objects are stored internally is up to the implementation. In case of need, these objects can be represented in system in form of handle(s), but they still should conform with protocol(s), specific to given kind of object. Objects, provided by surface should only be valid as long as surface valid, since different implementation(s) may use external resources, which are hard to preserve in exactly same state as they were, before surface is gone (image restart, window closed etc).
A system should aware of that and should rebind to newly available surface once it restarted and initialize appropriate resources/settings.
A basic class for surfaces are AthensSurface, which contain common functionality for all surfaces, while and rest is abstract methods, which should be implemented by subclasses.
Canvas
Canvas is an interface, bound to concrete surface through which all drawing operations are performed.
Bitmaps
A bitmaps storing a pixel data of predefined dimensions (x,y). A bitmap describes what components each pixel carries, as well as how these components laid out in memory (byte array) to access them.
Bitmaps should contain a following information:
- color component types:
- RGB color channels
- RGBA
- Intensity (grayscale, alpha channel etc)
- Grayscale intensity and Aplha
- component ordering (if there are more than one).
- A component values can be stored in multiple ways:
- 1, 8, 16, 32 bits per component, representing an unsigned integer values
- float
- compressed formats, like R5G5B6 etc
- scanline stride (a number of bytes between each scan line)
There are numerous ways how one could encode pixel data, but initially we want to support most commonly used ones.
Shapes
A shape defines an area on surface, for which painting operation can be performed using selected paint.
Currently there are two common used shape kinds:
Surfaces may support more kinds, like ellipse, rounded rectangle, oval etc. There are virtually no limits, what kinds of shapes could be supported, as long as shape could tell which pixels should be affected during painting.