Honestly I can't see why gfx & gfx.path "changed" need a manual
definition, instead of relying on EO. If the API needs to be
internal only, then EO needs to handle internal APIs. In this
case, the event was exposed as a C API but not a EO... why?
Alright, so this is a massive patch that is the result of
trying to get rid of unused or poorly implemented classes in
ector. Originally ector was meant to support VG but extend to
things like filters as well. At the moment, ector's design
makes it quite hard to plug in the filters.
For now I think it's easier to implement the GL support for
the filters directly in the engine, where I hope to interfere
as little as possible.
This massive patch keeps only the required minimum to support
a versatile gl buffer that can be mapped, drawn or rendered to (FBO).
It's extremely inefficient as it relies on glReadPixels and lots
of texture uploads, as well as conversions between ARGB and Alpha.
Another type of GL buffer is a wrap around an existing GL image,
but that one is read-only (map or draw: no write map, no FBO).
No, all the filters run fine, and the high-level implementation
(evas_filters.c) does not need to know whether the underlying engine
is SW or GL. One problem though appears with the blending or blurring
of some Alpha buffers, the colors are wrong.
This patch removes more lines than it adds so it must be good ;)
there is no way to mark output file as "precious", then cmake's
suggestion is to use add_custom_target() instead.
However that will always execute, so our generator script needs to be
smarter and only touch stuff when actually needed.
generate a static library for src/static_libs and use that as
LIBRARIES for the actual library, for those such as rg_etc that are
used multiple times will even speed up the final build by compiling
only once.
Although not used, they can be made into shared libraries that would
go inside /usr/lib/efl/support/v-1.19/libname.so
It has been discussed on the ML (thread: "[RFC] rename efl_self") and
IRC, and has been decided we should rename it to this in order to avoid
confusion with the already established meaning of self which is very
similar to what we were using it for, but didn't have complete overlap.
Kudos to Marcel Hollerbach for initiating the discussion and
fighting for it until he convinced a significant mass. :)
This commit breaks API, and depending on compiler potentially ABI.
@feature
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This removes some useless code in various places, where the
switch from eo_do() to standard function call was not properly
refactored.
This changes:
type ret = 0;
ret = my_eo_function();
return ret;
To:
return my_eo_function();
This removes the need for khronos_[u]int64_t as well as the special
typdef EvasGL[u]int64.
Hopefully this should work on all platforms (note: [u]int64_t is
used in Eina APIs, so it is already required for EFL apps).
Fixes T3200
Somehow, there was code in the tree that apparently isn't tested at all, even
once - if it was, the eo.c logic that performs inheritance checks would be
triggered. I don't know how this could have happened (actually I do, it's
Cedric's fault and he should be publicly shamed for it) but these checks
make sure this will never happen again. But since the code itself appears
to be untested, I don't know if there isn't any other brokenness in it.
But that's beyond the scope of this change, so for now, let's make sure
all our inheritance is at least formally correct.
Also, enable eo_interface.eo generated code in Eo itself so that Eo.Interface
can be used when inheriting.
@fix
This lets me narrow down the remaining cases of pointers across the EFL.
The void pointers will later need to be reevaluated on per-case basis and
replaced appropriately where possible/feasible.
This is a new incarnation of 0a03e63350. Our list
has grown to big again as people insist of adding the generated eolian files to
DISTCLEAN while BUILT_SOURCES will get removed durign the clean anyway.
Adding this file list twice will just make the argument list for rm to long to
work.
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
It's not actually implemented anywhere. There's a flag that's
never read. Proper support would require quite some work.
Once we actually implement fill_spread support, we can bring
the API back without breaking compatibility.
Summary: win-builds provide libcairo-2.dll and not libcairo.dlL
Test Plan: ector test progral
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3787
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.
Summary:
dlfcn.h is not available anymore on Windows, Evil provides all the
necessary declarations.
Reviewers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3577
@fix
This create some possible naming clash and is why I come up with
efl_gfx_color*_type_set functions. We will have to think about this more
carefully as it makes sense to now pass this colors directly to our color
API. Ideally the default 8 bits interface would become just a convenience
wrapper around the more complex possibility.
Summary: Add a field at the end of the structure for defining the color encoding.
Reviewers: cedric, Hermet, raster, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3530
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).
The original plan was to have two different surfaces for GL and SW,
but this is probably not going to happen anytime soon. So, move
the implementation back to lib/ector. This avoid a file duplication.
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.
Coverity reports that 'obj' is written twice with the same value
here., so fix this with a proper call to eo_do_super_ret
NB: Fixes Coverity CID1339786
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This make it part of the object initialization and will prevent the construction
of the object if the needed cairo function are not fund. So if Ector can create
the object, it can display them.
Summary:
Memory leak was caused by using the USE macro. So move the macro before
doing any allocation.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Differential Revision: https://phab.enlightenment.org/D3183
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
Jean-Philippe Andre
Gustavo Sverzut Barbieri
Daniel Kolesa
Cedric BAIL
Derek Foreman
Chris Michael
Hermet Park
Subhransu Mohanty
Stefan Schmidt
Tom Hacohen
Vitor Sousa
Carsten Haitzler
Jean Guyomarc'h
Vincent Torri
se.osadchy
Vivek Ellur
Srivardhan Hebbar