Back in January the release of DirectFB 1.6 was imminent, but then the developers behind this frame-buffer project ended up dragging the release on for stabilization reasons. This month is now the project’s revised target for doing the first DirectFB 1.6 stable release.
DirectFB 1.6 was slated for a January release, but seeing as this is a big release, it’s not too surprising it was delayed. DirectFB 1.6 introduces a new core architecture for eliminating multiple IPC/RPC mechanisms, eliminate shared memory, minimal global locks, and other enhancements to its core. DirectFB 1.6 also supports dynamic registration of window managers / compositors, new image providers (SVG / JPEG2000 / BMP), a Xine video provider, Xine/VDPAU acceleration support, new/re-written video drivers, performance enhancements, and much more.
In January, initial DirectFB Android support was merged as well.
From the DirectFB web-site, “The stabilization phase is still ongoing so that we expect the first release of DirectFB 1.6 in March.”
Meanwhile, further down the pipe is DirectFB 2.0. With DirectFB 2.0 they will be aiming for universal framework support, Cairo 2D library support, efficient 2D vector graphics and media handling, surface pools, an advanced hardware abstraction / driver integration layer, support for Khronos APIs, and full support for GTK. The Khronos APIs being talked about are OpenGL ES, OpenVG, and OpenMAX. Even completing a portion of these proposed action items will require extensive work. The ideas and plans for this far-out DirectFB 2.0 release have long been brought up on this Wiki page.
For those interested there’s also a DirectFB TODO list in the Git repository. Among the items there is finishing VT switching support, support for rotated screens, configuration system improvements, modularized pixel format support, and virtual window resolution with scrolling/panning support.