New commits:
http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=97ef6fc3ce2b6786bd3b1f721cde33076ce03e93
commit 97ef6fc3ce2b6786bd3b1f721cde33076ce03e93
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):
    
    IDirectFBRender ----.
           V            |
      CairoDirectFB     |
           V            |
    IDirectFBSurface ---'---->> Old Graphics Core ---->> Hardware
    
    Afterwards a lot of constellations make sense:
    
      CairoDFBRender
           V
     IDirectFBRender ---.--->>> New Graphics Core -->>>> Hardware/OpenVG
           V            |              vv
      CairoDirectFB((---:))? (( Old Graphics Core ---->> Hardware ))?
           V            |
    IDirectFBSurface ---'
    
    IDirectFBRender_Cairo simply does cairo_directfb_surface_create() or how it 
is called...
    
    The first full featured IDirectFBRender 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

Reply via email to