efl/src/lib/ector/Ector.h

158 lines
3.7 KiB
C
Raw Normal View History

#ifndef ECTOR_H_
#define ECTOR_H_
#include <Eina.h>
#include <Eo.h>
#ifdef EFL_BETA_API_SUPPORT
#include <Efl.h>
#endif
ector: Rename EAPI macro to ECTOR_API in Ector library 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 <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12226
2021-01-01 12:31:37 -08:00
#include <ector_api.h>
#ifdef __cplusplus
extern "C" {
#endif
/**
* @page ector_main Ector
*
* @date 2014 (created)
*
2020-02-28 02:01:56 -08:00
* @section ector_toc Table of Contents
*
* @li @ref ector_main_intro
* @li @ref ector_main_compiling
* @li @ref ector_main_next_steps
* @li @ref ector_main_intro_example
*
* @section ector_main_intro Introduction
*
* Ector is a retained mode drawing library designed to work
* for and with a scenegraph such as Evas, which supports several
* types of rendering surface including software and gl.
*
* @section ector_main_compiling How to compile the library
*
* Ector compiles automatically within EFL's build system, and is
* automatically linked with other components that need it. But it can
* also be built and used standalone, by compiling and linking your
* application with the compiler flags indicated by @c pkg-config. For
* example:
*
* @verbatim
* gcc -c -o my_main.o my_main.c `pkg-config --cflags ector`
*
* gcc -o my_application my_main.o `pkg-config --libs ector`
* @endverbatim
*
* See @ref pkgconfig
*
* @section ector_main_next_steps Recommended reading:
*
* @li @ref Ector_Surface
* @li @ref Ector_Renderer
*
* @section ector_main_intro_example Introductory Example
*
* @ref Ector_Tutorial
*
*
* @addtogroup Ector
* @{
*/
#ifdef EFL_BETA_API_SUPPORT
/**
* @typedef Ector_Surface
* The base type to render content into.
*/
typedef Eo Ector_Surface;
/**
* @typedef Ector_Renderer
* The base type describing what to render.
*/
typedef Eo Ector_Renderer;
/**
* @typedef Ector_Colorspace
* The definition of colorspace.
*/
// FIXME: Enable this when we have merged Emile
/* typedef Evas_Colorspace Ector_Colorspace; */
/**
* Priorities
*/
typedef enum _Ector_Priority
{
ECTOR_PRIORITY_NONE = 0,
ECTOR_PRIORITY_MARGINAL = 64,
ECTOR_PRIORITY_SECONDARY = 128,
ECTOR_PRIORITY_PRIMARY = 256,
} Ector_Priority;
/**
* What kind of update is being pushed
*/
typedef enum _Ector_Update_Type
{
ECTOR_UPDATE_BACKGROUND = 1, /* All the previous state in that area is reset to the new updated profile */
ECTOR_UPDATE_EMPTY = 2, /* Pushing empty area (no visible pixels at all, no need to read this surface to render it) */
ECTOR_UPDATE_ALPHA = 4, /* Pushing some transparent pixels (this impacts the under layer and will require reading back the surface where this surface is blitted) */
ECTOR_UPDATE_OPAQUE = 8 /* Pushing some opaque pixels (this means that there is no need to read the under layer when blitting this surface) */
} Ector_Update_Type;
/**
* @brief Init the ector subsystem
* @return @c EINA_TRUE on success.
*
* @see ector_shutfown()
*/
ector: Rename EAPI macro to ECTOR_API in Ector library 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 <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12226
2021-01-01 12:31:37 -08:00
ECTOR_API int ector_init(void);
/**
* @brief Shutdown the ector subsystem
* @return @c EINA_TRUE on success.
*
* @see ector_init()
*/
ector: Rename EAPI macro to ECTOR_API in Ector library 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 <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12226
2021-01-01 12:31:37 -08:00
ECTOR_API int ector_shutdown(void);
/**
* @brief Registers OpenGL API calls with the internal Ector_GL_API.
*
* @param glsym Function to use for looking up dynamically loaded symbols
* @param lib Dynamically loaded shared object, or RTLD_DEFAULT or RTLD_NEXT
* @return EINA_TRUE if call succeeded, EINA_FALSE if glsym was undefined or an error occurred
*
* The RTLD_DEFAULT and RTLD_NEXT pseudo-handles can be passed as lib to
* look up the first or next occurrence of the desired symbol in the dynamic
* library search order.
*
* @see dlsym()
*/
ector: Rename EAPI macro to ECTOR_API in Ector library 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 <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12226
2021-01-01 12:31:37 -08:00
ECTOR_API Eina_Bool ector_glsym_set(void *(*glsym)(void *lib, const char *name), void *lib);
2016-05-28 13:15:00 -07:00
/* Avoid redefinition of types */
#define _ECTOR_SURFACE_EO_CLASS_TYPE
#define _ECTOR_RENDERER_EO_CLASS_TYPE
#include "ector_surface.h"
#include "ector_renderer.h"
#include "ector_util.h"
#endif
/**
* @}
*/
#ifdef __cplusplus
}
#endif
#endif