2015-11-18 02:29:23 -08:00
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include "Ector_Software.h"
|
|
|
|
#include "ector_private.h"
|
|
|
|
#include "ector_software_private.h"
|
2015-12-10 00:15:25 -08:00
|
|
|
#include "ector_buffer.h"
|
2015-12-02 01:46:29 -08:00
|
|
|
#include "draw.h"
|
2015-11-30 22:22:20 -08:00
|
|
|
|
|
|
|
#define MY_CLASS ECTOR_SOFTWARE_BUFFER_CLASS
|
2015-11-18 02:29:23 -08:00
|
|
|
|
2015-12-10 00:15:25 -08:00
|
|
|
typedef struct _Ector_Software_Buffer_Map
|
|
|
|
{
|
|
|
|
EINA_INLIST;
|
2015-12-11 01:49:16 -08:00
|
|
|
uint8_t *ptr;
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
unsigned int size, stride; // in bytes
|
2015-12-11 01:49:16 -08:00
|
|
|
unsigned int x, y, w, h;
|
|
|
|
Efl_Gfx_Colorspace cspace;
|
2015-12-10 00:15:25 -08:00
|
|
|
Eina_Bool allocated;
|
2015-12-11 01:49:16 -08:00
|
|
|
Ector_Buffer_Access_Flag mode;
|
2015-12-10 00:15:25 -08:00
|
|
|
} Ector_Software_Buffer_Map;
|
|
|
|
|
2015-11-18 02:29:23 -08:00
|
|
|
/* FIXME: Conversion routines don't belong here */
|
|
|
|
static inline void
|
|
|
|
_pixels_argb_to_gry8_convert(uint8_t *dst, const uint32_t *src, int len)
|
|
|
|
{
|
|
|
|
int k;
|
|
|
|
for (k = 0; k < len; k++)
|
|
|
|
{
|
|
|
|
const uint32_t *s = src++;
|
|
|
|
*dst++ = A_VAL(s);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
_pixels_gry8_to_argb_convert(uint32_t *dst, const uint8_t *src, int len)
|
|
|
|
{
|
|
|
|
int k;
|
|
|
|
for (k = 0; k < len; k++)
|
|
|
|
{
|
|
|
|
uint8_t s = *src++;
|
2015-12-02 21:41:06 -08:00
|
|
|
*dst++ = DRAW_ARGB_JOIN(s, s, s, s);
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
EOLIAN static void
|
2019-09-10 21:12:08 -07:00
|
|
|
_ector_software_buffer_base_pixels_clear(Eo *obj EINA_UNUSED, Ector_Software_Buffer_Base_Data *pd)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2019-09-10 19:59:21 -07:00
|
|
|
if (!pd->pixels.u8) return;
|
2015-11-18 02:29:23 -08:00
|
|
|
|
2015-12-15 02:58:43 -08:00
|
|
|
if (pd->internal.maps)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2019-09-10 19:59:21 -07:00
|
|
|
ERR("Can not call pixels_clear when the buffer is mapped.");
|
|
|
|
return;
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
//TODO: Neccessary?
|
|
|
|
// efl_event_callback_call(obj, ECTOR_BUFFER_EVENT_DETACHED, pd->pixels.u8);
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
if (!pd->nofree) free(pd->pixels.u8);
|
|
|
|
pd->pixels.u8 = NULL;
|
|
|
|
pd->nofree = EINA_FALSE;
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
|
|
|
|
2019-12-05 22:22:56 -08:00
|
|
|
EOLIAN static Eina_Bool
|
2019-12-10 09:02:54 -08:00
|
|
|
_ector_software_buffer_base_ector_buffer_pixels_get(Eo *obj EINA_UNUSED, Ector_Software_Buffer_Base_Data *pd,
|
2019-12-05 22:22:56 -08:00
|
|
|
void **pixels, int* width, int* height, int* stride)
|
|
|
|
{
|
|
|
|
if (*pixels) *pixels = pd->pixels.u8;
|
|
|
|
if (*width) *width = pd->generic->w;
|
|
|
|
if (*height) *height = pd->generic->h;
|
|
|
|
if (*stride) *stride = pd->stride;
|
|
|
|
return pd->writable;
|
|
|
|
}
|
|
|
|
|
2015-11-18 02:29:23 -08:00
|
|
|
EOLIAN static Eina_Bool
|
2016-05-11 04:57:06 -07:00
|
|
|
_ector_software_buffer_base_ector_buffer_pixels_set(Eo *obj, Ector_Software_Buffer_Base_Data *pd,
|
2018-02-07 21:27:15 -08:00
|
|
|
void *pixels, int width, int height, int stride,
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
Efl_Gfx_Colorspace cspace, Eina_Bool writable)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2019-09-10 19:59:21 -07:00
|
|
|
unsigned int pxs;
|
2015-12-08 00:29:54 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
#if 0
|
|
|
|
if (pd->generic->immutable)
|
|
|
|
{
|
|
|
|
ERR("This buffer is immutable.");
|
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
|
|
|
#endif
|
2015-11-18 02:29:23 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
if (pd->internal.maps) return EINA_FALSE;
|
2015-11-18 02:29:23 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
if (cspace == EFL_GFX_COLORSPACE_ARGB8888) pxs = 4;
|
|
|
|
else if (cspace == EFL_GFX_COLORSPACE_GRY8) pxs = 1;
|
|
|
|
else return EINA_FALSE;
|
2015-11-30 22:22:20 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
if (stride == 0) stride = width * pxs;
|
|
|
|
else if (stride < (int)(width * pxs)) return EINA_FALSE;
|
2018-02-07 21:27:15 -08:00
|
|
|
|
2015-11-18 02:29:23 -08:00
|
|
|
if (pd->pixels.u8 && (pd->pixels.u8 != pixels))
|
2015-11-30 22:22:20 -08:00
|
|
|
_ector_software_buffer_base_pixels_clear(obj, pd);
|
2015-11-18 02:29:23 -08:00
|
|
|
|
|
|
|
if (pixels)
|
|
|
|
{
|
|
|
|
pd->pixels.u8 = pixels;
|
|
|
|
pd->nofree = EINA_TRUE;
|
|
|
|
pd->writable = !!writable;
|
|
|
|
}
|
2019-09-10 20:00:28 -07:00
|
|
|
else if (stride > 0 && height > 0)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
pd->pixels.u8 = calloc(stride * height, 1);
|
2015-11-18 02:29:23 -08:00
|
|
|
pd->nofree = EINA_FALSE;
|
|
|
|
pd->writable = EINA_TRUE;
|
|
|
|
}
|
2015-11-30 22:22:20 -08:00
|
|
|
pd->generic->w = width;
|
|
|
|
pd->generic->h = height;
|
|
|
|
pd->generic->cspace = cspace;
|
2015-11-18 02:29:23 -08:00
|
|
|
pd->stride = stride;
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
pd->pixel_size = pxs;
|
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
return EINA_TRUE;
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
|
|
|
|
2015-12-09 02:00:54 -08:00
|
|
|
EOLIAN static void *
|
2016-05-11 04:57:06 -07:00
|
|
|
_ector_software_buffer_base_ector_buffer_map(Eo *obj EINA_UNUSED, Ector_Software_Buffer_Base_Data *pd,
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
unsigned int *length, Ector_Buffer_Access_Flag mode,
|
|
|
|
unsigned int x, unsigned int y, unsigned int w, unsigned int h,
|
|
|
|
Efl_Gfx_Colorspace cspace EINA_UNUSED, unsigned int *stride)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2015-12-10 22:23:55 -08:00
|
|
|
Ector_Software_Buffer_Map *map = NULL;
|
2015-12-11 01:49:16 -08:00
|
|
|
Eina_Bool need_cow = EINA_FALSE;
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
unsigned int off, k, dst_stride, pxs, pxs_dest;
|
2015-12-10 22:23:55 -08:00
|
|
|
|
|
|
|
if (!w) w = pd->generic->w;
|
|
|
|
if (!h) h = pd->generic->h;
|
2015-11-18 02:29:23 -08:00
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
if (!pd->pixels.u8 || !pd->stride) goto on_fail;
|
|
|
|
|
2015-12-16 16:44:57 -08:00
|
|
|
if (((x + w) > pd->generic->w) || (y + h > pd->generic->h))
|
2019-09-10 19:59:21 -07:00
|
|
|
{
|
|
|
|
ERR("Invalid region requested: wanted %u,%u %ux%u but image is %ux%u",
|
|
|
|
x, y, w, h, pd->generic->w, pd->generic->h);
|
|
|
|
goto on_fail;
|
|
|
|
}
|
2015-12-09 02:00:54 -08:00
|
|
|
if ((mode & ECTOR_BUFFER_ACCESS_FLAG_WRITE) && !pd->writable)
|
2019-09-10 19:59:21 -07:00
|
|
|
{
|
|
|
|
ERR("Can not map a read-only buffer for writing");
|
|
|
|
goto on_fail;
|
|
|
|
}
|
2015-12-10 22:23:55 -08:00
|
|
|
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
pxs = (pd->generic->cspace == EFL_GFX_COLORSPACE_ARGB8888) ? 4 : 1;
|
2019-09-10 19:59:21 -07:00
|
|
|
if (cspace == EFL_GFX_COLORSPACE_ARGB8888) pxs_dest = 4;
|
|
|
|
else if (cspace == EFL_GFX_COLORSPACE_GRY8) pxs_dest = 1;
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
else
|
2019-09-10 19:59:21 -07:00
|
|
|
{
|
|
|
|
ERR("Unsupported colorspace: %u", cspace);
|
|
|
|
goto on_fail;
|
|
|
|
}
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
|
2015-12-11 01:49:16 -08:00
|
|
|
if ((mode & ECTOR_BUFFER_ACCESS_FLAG_WRITE) &&
|
|
|
|
(mode & ECTOR_BUFFER_ACCESS_FLAG_COW))
|
|
|
|
{
|
|
|
|
EINA_INLIST_FOREACH(pd->internal.maps, map)
|
|
|
|
if (map->mode == ECTOR_BUFFER_ACCESS_FLAG_READ)
|
|
|
|
{
|
|
|
|
need_cow = EINA_TRUE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-10 19:59:21 -07:00
|
|
|
map = calloc(1, sizeof(Ector_Software_Buffer_Map));
|
|
|
|
if (!map) goto on_fail;
|
2015-11-18 02:29:23 -08:00
|
|
|
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
off = (pxs * x) + (pd->stride * y);
|
|
|
|
dst_stride = w * pxs_dest;
|
|
|
|
|
2015-12-11 01:49:16 -08:00
|
|
|
map->mode = mode;
|
|
|
|
map->cspace = cspace;
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
map->stride = dst_stride;
|
2015-12-11 01:49:16 -08:00
|
|
|
map->x = x;
|
|
|
|
map->y = y;
|
|
|
|
map->w = w;
|
|
|
|
map->h = h;
|
|
|
|
|
2015-12-10 22:23:55 -08:00
|
|
|
if (cspace != pd->generic->cspace)
|
|
|
|
{
|
|
|
|
// convert on the fly
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
map->size = w * h * pxs_dest;
|
2015-12-10 22:23:55 -08:00
|
|
|
map->allocated = EINA_TRUE;
|
|
|
|
map->ptr = malloc(map->size);
|
2019-09-10 19:59:21 -07:00
|
|
|
if (!map->ptr) goto on_fail;
|
2015-12-10 22:23:55 -08:00
|
|
|
|
|
|
|
if (cspace == EFL_GFX_COLORSPACE_ARGB8888)
|
|
|
|
{
|
|
|
|
for (k = 0; k < h; k++)
|
|
|
|
_pixels_gry8_to_argb_convert((uint32_t *) map->ptr + (k * w), pd->pixels.u8 + off + (k * pd->stride), w);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (k = 0; k < h; k++)
|
2015-12-11 01:49:16 -08:00
|
|
|
_pixels_argb_to_gry8_convert(map->ptr + (k * w), (uint32_t *) (pd->pixels.u8 + off + (k * pd->stride)), w);
|
2015-12-10 22:23:55 -08:00
|
|
|
}
|
|
|
|
}
|
2015-12-11 01:49:16 -08:00
|
|
|
else if (need_cow)
|
|
|
|
{
|
|
|
|
// copy-on-write access
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
map->size = w * h * pxs_dest;
|
2015-12-11 01:49:16 -08:00
|
|
|
map->allocated = EINA_TRUE;
|
|
|
|
map->ptr = malloc(map->size);
|
2019-09-10 19:59:21 -07:00
|
|
|
|
|
|
|
if (!map->ptr) goto on_fail;
|
|
|
|
|
2015-12-11 01:49:16 -08:00
|
|
|
for (k = 0; k < h; k++)
|
|
|
|
memcpy(map->ptr + k * dst_stride, pd->pixels.u8 + x + (k + y) * pd->stride, dst_stride);
|
|
|
|
}
|
2015-12-10 22:23:55 -08:00
|
|
|
else
|
|
|
|
{
|
2015-12-11 01:49:16 -08:00
|
|
|
// direct access, zero-copy
|
2015-12-10 22:23:55 -08:00
|
|
|
map->size = (pd->stride * h) - off;
|
|
|
|
map->ptr = pd->pixels.u8 + off;
|
2015-12-11 01:49:16 -08:00
|
|
|
dst_stride = pd->stride;
|
2015-12-10 22:23:55 -08:00
|
|
|
}
|
2015-12-10 00:15:25 -08:00
|
|
|
|
2015-12-10 22:23:55 -08:00
|
|
|
pd->internal.maps = eina_inlist_prepend(pd->internal.maps, EINA_INLIST_GET(map));
|
|
|
|
if (length) *length = map->size;
|
2015-12-11 01:49:16 -08:00
|
|
|
if (stride) *stride = dst_stride;
|
2015-12-10 00:15:25 -08:00
|
|
|
return map->ptr;
|
2015-11-18 02:29:23 -08:00
|
|
|
|
|
|
|
on_fail:
|
2015-12-10 22:23:55 -08:00
|
|
|
free(map);
|
2015-11-18 02:29:23 -08:00
|
|
|
if (length) *length = 0;
|
|
|
|
if (stride) *stride = 0;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
EOLIAN static void
|
2016-05-11 04:57:06 -07:00
|
|
|
_ector_software_buffer_base_ector_buffer_unmap(Eo *obj EINA_UNUSED, Ector_Software_Buffer_Base_Data *pd,
|
2015-12-10 00:15:25 -08:00
|
|
|
void *data, unsigned int length)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2015-12-10 00:15:25 -08:00
|
|
|
Ector_Software_Buffer_Map *map;
|
2015-11-18 02:29:23 -08:00
|
|
|
if (!data) return;
|
2015-12-10 00:15:25 -08:00
|
|
|
|
|
|
|
EINA_INLIST_FOREACH(pd->internal.maps, map)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2015-12-10 22:23:55 -08:00
|
|
|
if ((map->ptr == data) && ((map->size == length) || (length == (unsigned int) -1)))
|
2015-12-10 00:15:25 -08:00
|
|
|
{
|
|
|
|
pd->internal.maps = eina_inlist_remove(pd->internal.maps, EINA_INLIST_GET(map));
|
2015-12-10 22:23:55 -08:00
|
|
|
if (map->allocated)
|
2015-12-11 01:49:16 -08:00
|
|
|
{
|
|
|
|
if (map->mode & ECTOR_BUFFER_ACCESS_FLAG_WRITE)
|
|
|
|
{
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
unsigned k;
|
2015-12-11 01:49:16 -08:00
|
|
|
|
|
|
|
if (map->cspace != pd->generic->cspace)
|
|
|
|
{
|
|
|
|
if (pd->generic->cspace == EFL_GFX_COLORSPACE_ARGB8888)
|
|
|
|
{
|
|
|
|
for (k = 0; k < map->h; k++)
|
|
|
|
_pixels_gry8_to_argb_convert((uint32_t *) (pd->pixels.u8 + (k + map->y) * pd->stride),
|
|
|
|
map->ptr + (k * map->w),
|
|
|
|
map->w);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (k = 0; k < map->h; k++)
|
|
|
|
_pixels_argb_to_gry8_convert(pd->pixels.u8 + (k + map->y) * pd->stride,
|
|
|
|
(uint32_t *) map->ptr + (k * map->w),
|
|
|
|
map->w);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (k = 0; k < map->h; k++)
|
|
|
|
{
|
|
|
|
memcpy(pd->pixels.u8 + map->x + (k + map->y) * pd->stride,
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
map->ptr + k * map->stride, map->stride);
|
2015-12-11 01:49:16 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(map->ptr);
|
|
|
|
}
|
2015-12-10 00:15:25 -08:00
|
|
|
free(map);
|
|
|
|
return;
|
|
|
|
}
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
2015-12-10 00:15:25 -08:00
|
|
|
|
|
|
|
CRI("Tried to unmap a non-mapped region!");
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
EOLIAN static Ector_Buffer_Flag
|
2018-04-17 11:09:44 -07:00
|
|
|
_ector_software_buffer_base_ector_buffer_flags_get(const Eo *obj EINA_UNUSED, Ector_Software_Buffer_Base_Data *pd)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
|
|
|
return ECTOR_BUFFER_FLAG_CPU_READABLE |
|
2015-12-15 02:58:43 -08:00
|
|
|
ECTOR_BUFFER_FLAG_DRAWABLE |
|
2015-11-18 02:29:23 -08:00
|
|
|
ECTOR_BUFFER_FLAG_CPU_READABLE_FAST |
|
|
|
|
(pd->writable ? (ECTOR_BUFFER_FLAG_CPU_WRITABLE |
|
evas filters: Refactor ector and gfx filters A LOT
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 ;)
2017-01-17 18:47:25 -08:00
|
|
|
ECTOR_BUFFER_FLAG_RENDERABLE |
|
2015-11-18 02:29:23 -08:00
|
|
|
ECTOR_BUFFER_FLAG_CPU_WRITABLE_FAST)
|
|
|
|
: 0);
|
|
|
|
}
|
|
|
|
|
2016-08-10 07:23:04 -07:00
|
|
|
EOLIAN static Efl_Object *
|
|
|
|
_ector_software_buffer_efl_object_constructor(Eo *obj, void *data EINA_UNUSED)
|
2015-11-30 22:22:20 -08:00
|
|
|
{
|
|
|
|
Ector_Software_Buffer_Base_Data *pd;
|
2016-08-15 06:44:41 -07:00
|
|
|
obj = efl_constructor(efl_super(obj, MY_CLASS));
|
|
|
|
pd = efl_data_scope_get(obj, ECTOR_SOFTWARE_BUFFER_BASE_MIXIN);
|
|
|
|
pd->generic = efl_data_ref(obj, ECTOR_BUFFER_MIXIN);
|
2015-11-30 22:22:20 -08:00
|
|
|
pd->generic->eo = obj;
|
|
|
|
return obj;
|
|
|
|
}
|
|
|
|
|
2015-11-18 02:29:23 -08:00
|
|
|
EOLIAN static void
|
2016-08-10 07:23:04 -07:00
|
|
|
_ector_software_buffer_efl_object_destructor(Eo *obj, void *data EINA_UNUSED)
|
2015-11-18 02:29:23 -08:00
|
|
|
{
|
2016-08-15 06:44:41 -07:00
|
|
|
Ector_Software_Buffer_Base_Data *pd = efl_data_scope_get(obj, ECTOR_SOFTWARE_BUFFER_BASE_MIXIN);
|
2015-11-30 22:22:20 -08:00
|
|
|
_ector_software_buffer_base_pixels_clear(obj, pd);
|
2016-08-15 06:44:41 -07:00
|
|
|
efl_data_unref(obj, pd->generic);
|
|
|
|
efl_destructor(efl_super(obj, MY_CLASS));
|
2015-12-10 00:15:25 -08:00
|
|
|
if (pd->internal.maps)
|
2019-09-10 19:59:21 -07:00
|
|
|
ERR("Pixel data is still mapped during destroy!");
|
2015-11-18 02:29:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
#include "ector_software_buffer.eo.c"
|
2015-11-30 22:22:20 -08:00
|
|
|
#include "ector_software_buffer_base.eo.c"
|