path: root/src/lib/ector/software/Ector_Software.h (follow)
AgeCommit message (Collapse)Author
2021-01-01ector: Rename EAPI macro to ECTOR_API in Ector libraryFelipe Magno de Almeida
Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. = The Rationale = EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))`. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <> Co-authored-by: Ricardo Campos <> Co-authored-by: Lucas Cavalcante de Sousa <> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision:
2019-07-22Ector.Renderer : Implement Ector.Renderer.(Software).Image classJunsuChoi
Summary: Implement a class and drawer that outputs image data from the Ector. Image data is output with a vector object and supports transform. Test Plan: N/A Reviewers: Hermet, smohanty, kimcinoo Reviewed By: Hermet Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision:
2018-01-18all: Simplify definition of EAPIVincent Torri
This will help in the transition from Autotools to Meson. This has been tested on Windows for which EFL_XXX_BUILD were first introduced.
2017-08-15ector: fix EAPI on WindowsVincent Torri
Signed-off-by: Cedric BAIL <>
2017-04-14evas filters: Refactor ector and gfx filters A LOTJean-Philippe Andre
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 ;)
2016-05-11Ector renderer software: Remove the no longer needed .Base hack.Tom Hacohen
2016-01-06Ector: Protect all headers by EFL_BETA_API_SUPPORTJean-Philippe Andre
Those Ector APIs are not stable!
2015-12-03Ector: Another minor code cleanupJean-Philippe Andre
Remove DATA8, DATA16, DATA32 Remove empty data structure Remove unnecessary typedef
2015-12-03Ector: Use Ector Buffer inside SW and Cairo renderersJean-Philippe Andre
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.
2015-12-03Ector: Implement pixel buffer supportJean-Philippe Andre
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
2015-07-16Ector: Fix potential build errors with double typedefJean-Philippe Andre
Depending on the compiler and its version, having twice a typedef on the same name may lead to a build failure. Thanks @mythri for the report.
2015-04-03ector: add software backend using FreeType rasterizer.Subhransu Sekhar Mohanty