I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
This indicates that a buffer can be used as a source to draw pixels.
Can't they all do that? Well, not exactly. A CPU buffer can't be drawn
by the GPU... not directly at least. That's what this flag is for.
In case you map a buffer once for read-only and once for write,
we can generate a temporary copy and return that instead. This
buffer will be copied back to the original surface once the COW
surface is unmapped.
Also use map to generate spans.
This should simplify some filters code, making things work,
albeit inefficiently. At least they should work.
Fix doc too.
Since Evas still relies entirely on Image_Entry and Evas_GL_Image,
we will need an engine-specific wrapper object creating a Buffer
around an existing cached image.
Currently only SW support is implemented. GL will be more fun to
do (with glReadPixels and whatnot).
It just makes things a bit more complicated and doesn't correspond
to a classic "map" operation anyways.
Also return void* instead of uint8_t*. This is more correct and
avoid extra casts.
This fixes the build for Windows. Thanks @vtorri for the report.
I'm not using "unsigned int" as uint was mostly used like DATA32,
ie. color data (one pixel color or a pixel buffer).
Rename a few things:
- draw helper -> efl_draw
- Ector_Rop -> Efl.Gfx.Render_Op
- ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops)
- ector_memfill -> draw_memset32 (and invert arg order to match memset)
The main rasterizer file is now draw.h in static_libs/draw
This is a non functional change, simple code refactor.
Ector Surface now inherits from Ector Buffer, and the current
two renderers (SW and Cairo SW) use Ector.Software.Buffer
implementations for pixel surfaces.
Basic pixel handling is merged and will allow easy extension
(color conversion, etc...).
Buffer classes are Mixins to be fully implemented by the final
class, such as: Ector.Software.Buffer, Ector.Software.Surface
or Ector.Cairo.Surface.
This is a large ugly commit. Sorry.
The code is quite a mess right now.
The objective of this patch is to propose a standardized
format for pixel buffers to use within Ector and Evas.
The basic EO API provided here is not meant to be the
fastest path for all operations, simply the most convenient
to generalize. Performance will be achieved by implementing
(or porting) custom draw functions.
This implements support for:
- Generic pixel buffers
- Generic buffer renderer to draw images with ector
- Software engine pixel buffers, ie. malloc buffers
- Software buffer renderer
Cairo support has not been implemented yet.
The only renderer is still extremely limited, as it does not
support Fill modes, Scaling, etc... yet.
Not a single line from this patch has been tested yet.
It compiles. That's pretty damn good for a start!
@feature
We have to use void in a function declaration if we want no function
parameters. Using just empty parenthesis means the function takes an
unspecified number of parameters.
We had it correct for most declarations and this series fixes it for
the rest.
Summary:
Null assignment has no effect in the caller function. So removed it.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Differential Revision: https://phab.enlightenment.org/D3184
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This really shows what parts are developed under windows. While it does not
matter where you develop please make sure that you do not introduce CRLF
endings and normal source files as executables.
Daniel Kolesa
Tom Hacohen
Jean-Philippe Andre
Subhransu Mohanty
Stefan Schmidt
Cedric BAIL
Vivek Ellur
Srivardhan Hebbar