New commits:
http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=0f9711df8f61cc30b617dbe6ff288c4ad0fe9e84
commit 0f9711df8f61cc30b617dbe6ff288c4ad0fe9e84
Author: Denis Oliver Kropp <[EMAIL PROTECTED]>
Date: Wed Mar 12 22:45:22 2008 +0100
[water] First checkin of new rendering, acceleration (and media)
architecture.
Following is a (mostly) copy'n'pasted excerpt of different mails:
The new rendering architecture will be the optimal solution with best
scalability
for any graphics accelerator from most primitive (DMA copy/fill) to most
advanced
with/without OpenVG support.
There will always be hardware with only limited vector graphics support if
at all
and for these it is DirectFB's job to provide decent acceleration with
breakdown
of higher level or unsupported vector graphics operations down to the
hardware
primitives.
It will be built on top of
a) hardware (implementing the new driver interface)
b) the existing rendering architecture
c) OpenVG/Cairo
While Cairo seems fine to become the software only implementation of the
new interface, it will also be implemented on top of it to leverage any
(non-)basic 2D acceleration available.
Same goes for OpenVG, but the intention in this case is to have a generic
implementation of the new API which provides generic hardware acceleration.
Building OpenVG on top makes sense as well as underneath, it just depends
on the hardware capabilities.
The new API is going a step further than OpenVG, Cairo and all those call
based immediate rendering interfaces. It will finally allow the last step
to move all information on the GPU side to just send a command for rendering
the complete frame of a user interface.
The new core is just one (the native) implementation of the new API.
For the short term I was thinking
about the following stack(s):
Before the new core "arrives" (is usable):
IWater --------.
V |
CairoDirectFB |
V |
IDirectFBSurface ---'---->> Old Graphics Core ---->> Hardware
Afterwards a lot of constellations make sense:
CairoWater
V
IWater --------.--->>> New Graphics Core -->>>> Hardware/OpenVG
V | vv
CairoDirectFB((---:))? (( Old Graphics Core ---->> Hardware ))?
V |
IDirectFBSurface ---'
IWater_Cairo simply does cairo_directfb_surface_create() or how it is
called...
The first full featured IWater implementation will be based ON Cairo, while
in the end most people will use it to implement Cairo and any other API
that is out yet.
What about Css, Networking, Javascript, DOM, MPEG-4, MHEG etc etc. ?
No problem, just add some new type(s) of joints, but outside of the Base
API using
extension mechanisms. Imagine GPUs that will walk the network and support
things like
applying a special kind of movement to an object or a complete tree as it
is hierarchical.
There will likely be an implementation of this new declarative drawing on
TI Davinci
as well, doing the whole scene graph traversal on DSP.
Thew new rendering core must be lightweight (micro core) with good
abstractions so basically
any actual (light/heavy weight) implementation, like transforming a curve
into a
line strip or emulating anti-aliasing with multiple passes, could be
implemented
as a module and plugged into the core. That way a lot of people will not
complain
about the added complexity too much. If they want to stick with their 20th
century
GUI elements, they can use the lightweight core without any extension and
have the
same amount of code (hopefully) as before.
Best case, of course, is when you have a lightweight core, because you can
simply
pass through all high level stuff to Cairo or OpenVG or even better
dedicated hw :)
We should take care that we will always be able to do simple mappings and
then
"translate" further via plugin modules, e.g. to render a gradient by using
a lot
of smaller elements with vertex coloring OR with a generated texture. That
is what
the driver and core need to negotiate (as outlined in my "managed
rendering").
Makefile.am | 2 +-
configure.in | 1 +
docs/html/Makefile.am | 5 +-
include/Makefile.am | 53 +-
include/directfb.h | 109 +++--
include/directfb_render.h | 1096 ++++++++++++++++++++++++++++++++++++++++
inputdrivers/lirc/lirc.c | 8 +-
src/Makefile.am | 3 +-
src/core/surface_pool.h | 2 +-
src/display/idirectfbsurface.c | 39 ++-
src/water/Makefile.am | 20 +
src/water/iwater.c | 750 +++++++++++++++++++++++++++
src/water/iwater.h | 62 +++
tests/Makefile.am | 7 +-
tests/dfbrender.c | 793 +++++++++++++++++++++++++++++
tools/gendoc.pl | 608 ++++++++++++-----------
tools/mknames.sh | 6 +-
17 files changed, 3178 insertions(+), 386 deletions(-)
_______________________________________________
directfb-cvs mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs
