2014-02-12 00:52:01 -08:00
|
|
|
/*
|
|
|
|
* \@file evas_filter.c
|
|
|
|
*
|
|
|
|
* Infrastructure for simple filters applied to RGBA and Alpha buffers.
|
2013-12-08 22:57:50 -08:00
|
|
|
* Originally used by font effects.
|
|
|
|
*
|
|
|
|
* Filters include:
|
|
|
|
* - Blur (Gaussian, Box, Motion) and Shadows
|
|
|
|
* - Bump maps (light effects)
|
|
|
|
* - Displacement maps
|
|
|
|
* - Color curves
|
|
|
|
* - Blending and masking
|
2014-02-12 00:52:01 -08:00
|
|
|
*
|
|
|
|
* The reference documentation can be found in evas_filter_parser.c
|
2013-12-08 22:57:50 -08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "evas_filter.h"
|
|
|
|
|
2014-01-16 18:19:02 -08:00
|
|
|
#ifdef EVAS_CSERVE2
|
|
|
|
# include "evas_cs2_private.h"
|
|
|
|
#endif
|
|
|
|
|
2015-06-03 03:59:11 -07:00
|
|
|
#include "evas_filter_private.h"
|
2015-12-08 17:45:53 -08:00
|
|
|
#include <Ector.h>
|
|
|
|
#include <software/Ector_Software.h>
|
|
|
|
#include "evas_ector_buffer.eo.h"
|
2015-06-03 03:59:11 -07:00
|
|
|
|
2015-05-18 01:35:49 -07:00
|
|
|
#define _assert(a) if (!(a)) CRI("Failed on %s", #a);
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
static void _buffer_free(Evas_Filter_Buffer *fb);
|
|
|
|
static void _command_del(Evas_Filter_Context *ctx, Evas_Filter_Command *cmd);
|
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
|
|
|
static Evas_Filter_Buffer *_buffer_alloc_new(Evas_Filter_Context *ctx, int w, int h, Eina_Bool alpha_only, Eina_Bool render, Eina_Bool draw);
|
2017-03-22 00:55:26 -07:00
|
|
|
static void _filter_buffer_unlock_all(Evas_Filter_Context *ctx);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
#define DRAW_COLOR_SET(r, g, b, a) do { cmd->draw.R = r; cmd->draw.G = g; cmd->draw.B = b; cmd->draw.A = a; } while (0)
|
2014-01-02 01:44:01 -08:00
|
|
|
#define DRAW_CLIP_SET(_x, _y, _w, _h) do { cmd->draw.clip.x = _x; cmd->draw.clip.y = _y; cmd->draw.clip.w = _w; cmd->draw.clip.h = _h; } while (0)
|
2013-12-31 00:51:09 -08:00
|
|
|
#define DRAW_FILL_SET(fmode) do { cmd->draw.fillmode = fmode; } while (0)
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
/* Main functions */
|
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
#define _free(ptr) free(ptr)
|
|
|
|
//eina_freeq_ptr_main_add(ptr, NULL, sizeof(*ptr))
|
|
|
|
|
2018-10-26 03:33:05 -07:00
|
|
|
|
|
|
|
/* FIXME: This code is come from a log by
|
|
|
|
CRI<14853>:eo lib/eo/eo.c:1894 efl_unref() Calling efl_unref instead of efl_del or efl_parent_set(NULL).
|
|
|
|
Temporary fallback in place triggered." When u get correct method, please fix this. */
|
2018-10-26 03:30:28 -07:00
|
|
|
static void
|
|
|
|
_buffer_del(Eo *buffer)
|
|
|
|
{
|
|
|
|
if (!buffer) return;
|
|
|
|
|
|
|
|
if (efl_parent_get(buffer))
|
|
|
|
efl_del(buffer);
|
|
|
|
else
|
|
|
|
efl_unref(buffer);
|
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
Evas_Filter_Context *
|
2017-01-05 04:29:32 -08:00
|
|
|
evas_filter_context_new(Evas_Public_Data *evas, Eina_Bool async, void *user_data)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Context *ctx;
|
|
|
|
|
2014-01-16 18:19:02 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(evas, NULL);
|
2017-01-17 03:48:31 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(evas->engine.func->gfx_filter_supports, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(evas->engine.func->gfx_filter_process, NULL);
|
2014-01-16 18:19:02 -08:00
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
ctx = calloc(1, sizeof(Evas_Filter_Context));
|
|
|
|
if (!ctx) return NULL;
|
|
|
|
|
|
|
|
ctx->evas = evas;
|
2014-01-22 23:54:50 -08:00
|
|
|
ctx->async = async;
|
2017-01-05 04:29:32 -08:00
|
|
|
ctx->user_data = user_data;
|
2017-01-16 23:13:35 -08:00
|
|
|
ctx->buffer_scaled_get = &evas_filter_buffer_scaled_get;
|
2017-03-22 03:18:41 -07:00
|
|
|
ctx->gl = (ENFN->gl_surface_read_pixels != NULL);
|
2017-09-04 03:08:02 -07:00
|
|
|
ctx->refcount = 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
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2017-01-05 04:29:32 -08:00
|
|
|
void *
|
|
|
|
evas_filter_context_data_get(Evas_Filter_Context *ctx)
|
2017-01-03 23:50:09 -08:00
|
|
|
{
|
2017-01-05 04:29:32 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2017-01-03 23:50:09 -08:00
|
|
|
|
2017-01-05 04:29:32 -08:00
|
|
|
return ctx->user_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
Eina_Bool
|
|
|
|
evas_filter_context_async_get(Evas_Filter_Context *ctx)
|
|
|
|
{
|
|
|
|
return ctx->async;
|
2017-01-03 23:50:09 -08:00
|
|
|
}
|
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
void
|
|
|
|
evas_filter_context_size_get(Evas_Filter_Context *ctx, int *w, int *h)
|
|
|
|
{
|
|
|
|
if (w) *w = ctx->w;
|
|
|
|
if (h) *h = ctx->h;
|
|
|
|
}
|
|
|
|
|
2014-02-13 19:07:54 -08:00
|
|
|
/* Private function to reset the filter context. Used from parser.c */
|
2013-12-08 22:57:50 -08:00
|
|
|
void
|
2017-03-22 00:55:26 -07:00
|
|
|
evas_filter_context_clear(Evas_Filter_Context *ctx, Eina_Bool keep_buffers)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
2017-03-22 00:55:26 -07:00
|
|
|
Evas_Filter_Buffer *fb;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (!ctx) return;
|
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
if (ctx->target.surface) ENFN->image_free(ENC, ctx->target.surface);
|
|
|
|
if (ctx->target.mask) ENFN->image_free(ENC, ctx->target.mask);
|
2017-03-22 00:55:26 -07:00
|
|
|
ctx->target.surface = NULL;
|
|
|
|
ctx->target.mask = NULL;
|
|
|
|
|
|
|
|
if (!keep_buffers)
|
|
|
|
{
|
|
|
|
ctx->last_buffer_id = 0;
|
|
|
|
EINA_LIST_FREE(ctx->buffers, fb)
|
|
|
|
_buffer_free(fb);
|
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
ctx->last_command_id = 0;
|
2017-03-22 00:55:26 -07:00
|
|
|
EINA_INLIST_FREE(ctx->commands, cmd)
|
|
|
|
_command_del(ctx, cmd);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
// Note: don't reset post_run, as it it set by the client
|
|
|
|
}
|
|
|
|
|
2014-01-16 18:19:02 -08:00
|
|
|
static void
|
|
|
|
_filter_buffer_backing_free(Evas_Filter_Buffer *fb)
|
|
|
|
{
|
2015-12-08 17:45:53 -08:00
|
|
|
if (!fb || !fb->buffer) return;
|
2018-10-26 03:30:28 -07:00
|
|
|
_buffer_del((Eo *)fb->buffer);
|
2015-12-08 17:45:53 -08:00
|
|
|
fb->buffer = NULL;
|
2014-03-06 16:36:16 -08:00
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
/** @hidden private render proxy objects */
|
|
|
|
void
|
2017-08-25 10:52:29 -07:00
|
|
|
evas_filter_context_proxy_render_all(Evas_Filter_Context *ctx, Eo *eo_obj, void *output,
|
2015-12-09 22:50:40 -08:00
|
|
|
Eina_Bool do_async)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Object_Protected_Data *source;
|
|
|
|
Evas_Object_Protected_Data *obj;
|
2017-03-22 00:55:26 -07:00
|
|
|
void *proxy_surface;
|
2013-12-08 22:57:50 -08:00
|
|
|
Evas_Filter_Buffer *fb;
|
|
|
|
Eina_List *li;
|
|
|
|
|
2015-12-09 22:50:40 -08:00
|
|
|
if (!ctx->has_proxies) return;
|
2016-08-15 06:44:41 -07:00
|
|
|
obj = efl_data_scope_get(eo_obj, EFL_CANVAS_OBJECT_CLASS);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
if (fb->source)
|
|
|
|
{
|
|
|
|
// TODO: Lock current object as proxyrendering (see image obj)
|
2016-08-15 06:44:41 -07:00
|
|
|
source = efl_data_scope_get(fb->source, EFL_CANVAS_OBJECT_CLASS);
|
2015-05-18 01:35:49 -07:00
|
|
|
_assert(fb->w == source->cur->geometry.w);
|
|
|
|
_assert(fb->h == source->cur->geometry.h);
|
2017-03-22 00:55:26 -07:00
|
|
|
proxy_surface = source->proxy->surface;
|
2013-12-08 22:57:50 -08:00
|
|
|
if (source->proxy->surface && !source->proxy->redraw)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Source already rendered: '%s' of type '%s'",
|
2016-08-15 06:44:41 -07:00
|
|
|
fb->source_name, efl_class_name_get(efl_class_get(fb->source)));
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Source needs to be rendered: '%s' of type '%s' (%s)",
|
2016-08-15 06:44:41 -07:00
|
|
|
fb->source_name, efl_class_name_get(efl_class_get(fb->source)),
|
2014-03-10 00:05:55 -07:00
|
|
|
source->proxy->redraw ? "redraw" : "no surface");
|
2017-08-25 10:52:29 -07:00
|
|
|
evas_render_proxy_subrender(ctx->evas->evas, output, fb->source, eo_obj, obj, EINA_FALSE, do_async);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
2017-03-22 00:55:26 -07:00
|
|
|
if (fb->buffer)
|
|
|
|
{
|
|
|
|
void *old_surface;
|
|
|
|
|
|
|
|
old_surface = evas_ector_buffer_drawable_image_get(fb->buffer);
|
2017-04-05 03:19:36 -07:00
|
|
|
if (old_surface)
|
|
|
|
{
|
|
|
|
evas_ector_buffer_engine_image_release(fb->buffer, old_surface);
|
|
|
|
if (old_surface && (old_surface != proxy_surface))
|
|
|
|
_filter_buffer_backing_free(fb);
|
|
|
|
}
|
2017-03-22 00:55:26 -07:00
|
|
|
}
|
2015-12-09 22:50:40 -08:00
|
|
|
XDBG("Source #%d '%s' has dimensions %dx%d", fb->id, fb->source_name, fb->w, fb->h);
|
2017-04-24 15:09:25 -07:00
|
|
|
if (!fb->buffer) fb->buffer = ENFN->ector_buffer_wrap(ENC, obj->layer->evas->evas, source->proxy->surface);
|
2015-10-07 23:01:21 -07:00
|
|
|
fb->alpha_only = EINA_FALSE;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
void
|
2017-08-25 10:51:53 -07:00
|
|
|
_evas_filter_context_program_reuse(void *engine, void *output, Evas_Filter_Context *ctx)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *fb;
|
2017-03-22 00:55:26 -07:00
|
|
|
Eina_List *li;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
_filter_buffer_unlock_all(ctx);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
{
|
|
|
|
void *dc, *surface;
|
|
|
|
|
|
|
|
fb->used = EINA_FALSE;
|
|
|
|
fb->locked = EINA_FALSE;
|
|
|
|
|
|
|
|
if (!fb->is_render) continue;
|
|
|
|
if (fb->source) continue;
|
|
|
|
|
|
|
|
surface = evas_ector_buffer_render_image_get(fb->buffer);
|
|
|
|
if (!surface) continue;
|
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
dc = ENFN->context_new(engine);
|
|
|
|
ENFN->context_color_set(engine, dc, 0, 0, 0, 0);
|
|
|
|
ENFN->context_render_op_set(engine, dc, EVAS_RENDER_COPY);
|
|
|
|
ENFN->rectangle_draw(engine, output, dc, surface, 0, 0, fb->w, fb->h, ctx->async);
|
|
|
|
ENFN->context_free(engine, dc);
|
2017-03-22 00:55:26 -07:00
|
|
|
fb->dirty = EINA_FALSE;
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
evas_ector_buffer_engine_image_release(fb->buffer, surface);
|
|
|
|
}
|
2017-03-22 00:55:26 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_context_destroy(void *data)
|
|
|
|
{
|
|
|
|
Evas_Filter_Context *ctx = data;
|
2015-08-31 01:28:58 -07:00
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
EINA_SAFETY_ON_FALSE_RETURN(ctx->refcount == 0);
|
2017-03-22 00:55:26 -07:00
|
|
|
evas_filter_context_clear(ctx, EINA_FALSE);
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
evas_filter_context_ref(Evas_Filter_Context *ctx)
|
|
|
|
{
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, -1);
|
|
|
|
|
|
|
|
#ifdef FILTERS_DEBUG
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(eina_main_loop_is(), -1);
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(ctx->refcount > 0, -1);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return (++ctx->refcount);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
void
|
2017-09-04 03:08:02 -07:00
|
|
|
evas_filter_context_unref(Evas_Filter_Context *ctx)
|
2017-03-22 00:55:26 -07:00
|
|
|
{
|
2017-04-12 20:08:31 -07:00
|
|
|
if (!ctx) return;
|
|
|
|
|
|
|
|
#ifdef FILTERS_DEBUG
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN(eina_main_loop_is());
|
2017-09-04 03:08:02 -07:00
|
|
|
EINA_SAFETY_ON_FALSE_RETURN(ctx->refcount > 0);
|
2017-04-12 20:08:31 -07:00
|
|
|
#endif
|
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
if ((--ctx->refcount) != 0) return;
|
2017-04-12 20:08:31 -07:00
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
if (!ctx->running)
|
2017-03-22 00:55:26 -07:00
|
|
|
_context_destroy(ctx);
|
2017-09-04 03:08:02 -07:00
|
|
|
// else: post_run_cb will be called
|
2017-03-22 00:55:26 -07:00
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
void
|
|
|
|
evas_filter_context_post_run_callback_set(Evas_Filter_Context *ctx,
|
|
|
|
Evas_Filter_Cb cb, void *data)
|
|
|
|
{
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN(ctx);
|
|
|
|
ctx->post_run.cb = cb;
|
|
|
|
ctx->post_run.data = data;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Evas_Filter_Buffer *
|
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
|
|
|
_buffer_empty_new(Evas_Filter_Context *ctx, int w, int h, Eina_Bool alpha_only,
|
|
|
|
Eina_Bool transient)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *fb;
|
|
|
|
|
|
|
|
fb = calloc(1, sizeof(Evas_Filter_Buffer));
|
|
|
|
if (!fb) return NULL;
|
|
|
|
|
|
|
|
fb->id = ++(ctx->last_buffer_id);
|
|
|
|
fb->ctx = ctx;
|
|
|
|
fb->alpha_only = alpha_only;
|
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
|
|
|
fb->transient = transient;
|
2013-12-08 22:57:50 -08:00
|
|
|
fb->w = w;
|
|
|
|
fb->h = h;
|
|
|
|
|
|
|
|
ctx->buffers = eina_list_append(ctx->buffers, fb);
|
|
|
|
return fb;
|
|
|
|
}
|
|
|
|
|
2015-12-08 17:45:53 -08:00
|
|
|
static Ector_Buffer *
|
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_create(Evas_Filter_Buffer const *fb, Eina_Bool render, Eina_Bool draw)
|
2013-12-08 22:57:50 -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
|
|
|
Efl_Gfx_Colorspace cspace = EFL_GFX_COLORSPACE_ARGB8888;
|
2016-01-04 01:00:30 -08:00
|
|
|
Ector_Buffer_Flag flags;
|
2015-12-08 17:45:53 -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
|
|
|
// FIXME: Once all filters are GL buffers need not be CPU accessible
|
2016-01-04 01:00:30 -08:00
|
|
|
flags = ECTOR_BUFFER_FLAG_CPU_READABLE | 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
|
|
|
if (render) flags |= ECTOR_BUFFER_FLAG_RENDERABLE;
|
|
|
|
if (draw) flags |= ECTOR_BUFFER_FLAG_DRAWABLE;
|
|
|
|
if (fb->alpha_only) cspace = EFL_GFX_COLORSPACE_GRY8;
|
2016-01-04 01:00:30 -08:00
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
return fb->ENFN->ector_buffer_new(FB_ENC, fb->ctx->evas->evas,
|
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
|
|
|
fb->w, fb->h, cspace, flags);
|
2013-12-11 22:54:33 -08:00
|
|
|
}
|
|
|
|
|
2014-01-22 21:58:05 -08:00
|
|
|
Eina_Bool
|
2015-05-18 01:35:49 -07:00
|
|
|
evas_filter_context_buffers_allocate_all(Evas_Filter_Context *ctx)
|
2014-01-22 21:58:05 -08:00
|
|
|
{
|
2014-01-22 23:54:50 -08:00
|
|
|
Evas_Filter_Command *cmd;
|
2014-01-22 21:58:05 -08:00
|
|
|
Evas_Filter_Buffer *fb;
|
2017-04-05 03:19:36 -07:00
|
|
|
Eina_List *li, *li2;
|
2015-05-18 01:35:49 -07:00
|
|
|
unsigned w, h;
|
2014-01-22 21:58:05 -08:00
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, EINA_FALSE);
|
2015-05-18 01:35:49 -07:00
|
|
|
w = ctx->w;
|
2015-05-26 00:12:00 -07:00
|
|
|
h = ctx->h;
|
2014-01-22 23:54:50 -08:00
|
|
|
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Allocating all buffers based on output size %ux%u", w, h);
|
2014-01-22 23:54:50 -08:00
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
fb->cleanup = EINA_TRUE;
|
|
|
|
|
2014-01-22 23:54:50 -08:00
|
|
|
EINA_INLIST_FOREACH(ctx->commands, cmd)
|
2014-01-22 21:58:05 -08:00
|
|
|
{
|
2014-01-22 23:54:50 -08:00
|
|
|
Evas_Filter_Fill_Mode fillmode = cmd->draw.fillmode;
|
2014-02-11 17:14:38 -08:00
|
|
|
Evas_Filter_Buffer *in, *out;
|
2014-01-22 23:54:50 -08:00
|
|
|
|
|
|
|
in = cmd->input;
|
2017-08-02 03:58:02 -07:00
|
|
|
EINA_SAFETY_ON_NULL_GOTO(in, alloc_fail);
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
in->cleanup = EINA_FALSE;
|
2014-01-22 23:54:50 -08:00
|
|
|
if (!in->w && !in->h)
|
|
|
|
{
|
|
|
|
in->w = w;
|
|
|
|
in->h = h;
|
|
|
|
}
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
if (cmd->mask)
|
|
|
|
cmd->mask->cleanup = EINA_FALSE;
|
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
// FIXME: No need for stretch buffers with GL!
|
2014-01-22 23:54:50 -08:00
|
|
|
if (fillmode & EVAS_FILTER_FILL_MODE_STRETCH_XY)
|
|
|
|
{
|
|
|
|
unsigned sw = w, sh = h;
|
|
|
|
|
|
|
|
switch (cmd->mode)
|
|
|
|
{
|
|
|
|
case EVAS_FILTER_MODE_BLEND:
|
|
|
|
in = cmd->input;
|
|
|
|
break;
|
|
|
|
case EVAS_FILTER_MODE_BUMP:
|
|
|
|
case EVAS_FILTER_MODE_DISPLACE:
|
|
|
|
case EVAS_FILTER_MODE_MASK:
|
|
|
|
in = cmd->mask;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
CRI("Invalid fillmode set for command %d", cmd->mode);
|
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
2014-01-22 21:58:05 -08:00
|
|
|
|
2017-08-02 03:58:02 -07:00
|
|
|
EINA_SAFETY_ON_NULL_GOTO(in, alloc_fail);
|
2014-01-22 23:54:50 -08:00
|
|
|
if (in->w) sw = in->w;
|
|
|
|
if (in->h) sh = in->h;
|
|
|
|
|
|
|
|
if ((sw != w) || (sh != h))
|
|
|
|
{
|
|
|
|
if (fillmode & EVAS_FILTER_FILL_MODE_STRETCH_X)
|
|
|
|
sw = w;
|
|
|
|
if (fillmode & EVAS_FILTER_FILL_MODE_STRETCH_Y)
|
|
|
|
sh = h;
|
|
|
|
|
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
|
|
|
fb = _buffer_alloc_new(ctx, sw, sh, in->alpha_only, 1, 1);
|
2015-12-09 22:12:23 -08:00
|
|
|
XDBG("Allocated temporary buffer #%d of size %ux%u %s",
|
|
|
|
fb ? fb->id : -1, sw, sh, in->alpha_only ? "alpha" : "rgba");
|
2014-03-11 00:18:41 -07:00
|
|
|
if (!fb) goto alloc_fail;
|
2014-01-22 23:54:50 -08:00
|
|
|
fb->transient = EINA_TRUE;
|
2017-04-05 03:19:36 -07:00
|
|
|
fb->cleanup = EINA_FALSE;
|
2014-01-22 23:54:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmd->draw.need_temp_buffer)
|
|
|
|
{
|
|
|
|
unsigned sw = w, sh = h;
|
|
|
|
|
|
|
|
in = cmd->input;
|
|
|
|
if (in->w) sw = in->w;
|
|
|
|
if (in->h) sh = in->h;
|
|
|
|
|
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
|
|
|
fb = _buffer_alloc_new(ctx, sw, sh, in->alpha_only, 1, 1);
|
2015-12-09 22:12:23 -08:00
|
|
|
XDBG("Allocated temporary buffer #%d of size %ux%u %s",
|
|
|
|
fb ? fb->id : -1, sw, sh, in->alpha_only ? "alpha" : "rgba");
|
2014-03-11 00:18:41 -07:00
|
|
|
if (!fb) goto alloc_fail;
|
2014-01-22 23:54:50 -08:00
|
|
|
fb->transient = EINA_TRUE;
|
2017-04-05 03:19:36 -07:00
|
|
|
fb->cleanup = EINA_FALSE;
|
2014-01-22 23:54:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
out = cmd->output;
|
2017-04-05 03:19:36 -07:00
|
|
|
out->cleanup = EINA_FALSE;
|
2014-01-22 23:54:50 -08:00
|
|
|
if (!out->w && !out->h)
|
|
|
|
{
|
|
|
|
out->w = w;
|
|
|
|
out->h = h;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
{
|
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
|
|
|
Eina_Bool render = EINA_FALSE, draw = EINA_FALSE;
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
if (fb->source)
|
|
|
|
{
|
|
|
|
fb->cleanup = EINA_FALSE;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (fb->buffer || fb->cleanup)
|
2014-01-22 23:54:50 -08:00
|
|
|
continue;
|
|
|
|
|
2014-01-22 21:58:05 -08:00
|
|
|
if (!fb->w && !fb->h)
|
|
|
|
{
|
2014-03-06 16:36:16 -08:00
|
|
|
ERR("Size of buffer %d should be known at this point. Is this a dangling buffer?", fb->id);
|
2014-01-22 23:54:50 -08:00
|
|
|
continue;
|
2014-01-22 21:58:05 -08:00
|
|
|
}
|
2014-01-22 23:54:50 -08:00
|
|
|
|
2017-04-02 23:34:10 -07:00
|
|
|
// Skip input buffer, allocate it in input render phase
|
|
|
|
if (fb->id == EVAS_FILTER_BUFFER_INPUT_ID)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
render = fb->is_render || fb->transient;
|
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
|
|
|
draw |= (fb->id == EVAS_FILTER_BUFFER_OUTPUT_ID);
|
|
|
|
|
|
|
|
fb->buffer = _ector_buffer_create(fb, render, draw);
|
2015-12-08 17:45:53 -08:00
|
|
|
XDBG("Allocated buffer #%d of size %ux%u %s: %p",
|
|
|
|
fb->id, fb->w, fb->h, fb->alpha_only ? "alpha" : "rgba", fb->buffer);
|
|
|
|
if (!fb->buffer) goto alloc_fail;
|
2014-01-22 21:58:05 -08:00
|
|
|
}
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
EINA_LIST_FOREACH_SAFE(ctx->buffers, li, li2, fb)
|
|
|
|
{
|
|
|
|
if (fb->cleanup)
|
|
|
|
{
|
|
|
|
XDBG("Cleanup buffer #%d %dx%d %s", fb->id, fb->w, fb->h, fb->alpha_only ? "alpha" : "rgba");
|
|
|
|
ctx->buffers = eina_list_remove_list(ctx->buffers, li);
|
|
|
|
_buffer_free(fb);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-22 21:58:05 -08:00
|
|
|
return EINA_TRUE;
|
2014-03-11 00:18:41 -07:00
|
|
|
|
|
|
|
alloc_fail:
|
|
|
|
ERR("Buffer allocation failed! Context size: %dx%d", w, h);
|
|
|
|
return EINA_FALSE;
|
2014-01-22 21:58:05 -08:00
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
int
|
2017-03-22 00:55:26 -07:00
|
|
|
evas_filter_buffer_empty_new(Evas_Filter_Context *ctx, int w, int h, Eina_Bool alpha_only)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *fb;
|
2017-03-22 00:55:26 -07:00
|
|
|
Eina_List *li;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, -1);
|
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
{
|
|
|
|
if ((fb->alpha_only == alpha_only) &&
|
|
|
|
(fb->w == w) && (fb->h == h) && !fb->dirty && !fb->used)
|
|
|
|
{
|
|
|
|
fb->used = EINA_TRUE;
|
|
|
|
return fb->id;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fb = _buffer_empty_new(ctx, w, h, alpha_only, EINA_FALSE);
|
2013-12-08 22:57:50 -08:00
|
|
|
if (!fb) return -1;
|
|
|
|
|
2017-03-22 00:55:26 -07:00
|
|
|
fb->used = EINA_TRUE;
|
|
|
|
return fb->id;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
evas_filter_buffer_proxy_new(Evas_Filter_Context *ctx, Evas_Filter_Proxy_Binding *pb,
|
|
|
|
int *w, int *h)
|
|
|
|
{
|
|
|
|
Evas_Object_Protected_Data *source;
|
|
|
|
Evas_Filter_Buffer *fb;
|
|
|
|
Eina_List *li;
|
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, -1);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(pb, -1);
|
|
|
|
|
|
|
|
source = efl_data_scope_get(pb->eo_source, EFL_CANVAS_OBJECT_CLASS);
|
|
|
|
if (!source) return -1;
|
|
|
|
|
|
|
|
// FIXME: This is not true if the source is an evas image
|
|
|
|
*w = source->cur->geometry.w;
|
|
|
|
*h = source->cur->geometry.h;
|
|
|
|
|
|
|
|
EINA_LIST_FOREACH(ctx->buffers, li, fb)
|
|
|
|
{
|
|
|
|
if (pb->eo_source == fb->source)
|
|
|
|
{
|
|
|
|
if (fb->used) return -1;
|
|
|
|
if (fb->alpha_only) return -1;
|
|
|
|
if (!eina_streq(pb->name, fb->source_name)) return -1;
|
|
|
|
if ((*w != fb->w) || (*h != fb->h)) return -1;
|
|
|
|
|
|
|
|
fb->used = EINA_TRUE;
|
|
|
|
return fb->id;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fb = _buffer_empty_new(ctx, *w, *h, EINA_FALSE, EINA_FALSE);
|
|
|
|
if (!fb) return -1;
|
|
|
|
|
|
|
|
fb->source = efl_ref(pb->eo_source);
|
|
|
|
fb->source_name = eina_stringshare_add(pb->name);
|
|
|
|
|
|
|
|
fb->used = EINA_TRUE;
|
2013-12-08 22:57:50 -08:00
|
|
|
return fb->id;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static Evas_Filter_Buffer *
|
|
|
|
_buffer_alloc_new(Evas_Filter_Context *ctx, int w, int h, Eina_Bool alpha_only,
|
|
|
|
Eina_Bool render, Eina_Bool draw)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *fb;
|
|
|
|
|
2014-01-22 23:54:50 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(w > 0 && h > 0, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
fb = calloc(1, sizeof(Evas_Filter_Buffer));
|
2014-01-22 23:54:50 -08:00
|
|
|
if (!fb) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
fb->id = ++(ctx->last_buffer_id);
|
|
|
|
fb->ctx = ctx;
|
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
|
|
|
fb->w = w;
|
|
|
|
fb->h = h;
|
|
|
|
fb->alpha_only = alpha_only;
|
2017-03-22 00:55:26 -07:00
|
|
|
fb->is_render = render;
|
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
|
|
|
fb->buffer = _ector_buffer_create(fb, render, draw);
|
|
|
|
if (!fb->buffer)
|
2013-12-08 22:57:50 -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
|
|
|
ERR("Failed to create ector buffer!");
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(fb);
|
2014-01-22 23:54:50 -08:00
|
|
|
return NULL;
|
2013-12-08 22:57:50 -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
|
|
|
ctx->buffers = eina_list_append(ctx->buffers, fb);
|
2014-01-22 23:54:50 -08:00
|
|
|
return fb;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_buffer_free(Evas_Filter_Buffer *fb)
|
|
|
|
{
|
2014-01-16 18:19:02 -08:00
|
|
|
_filter_buffer_backing_free(fb);
|
2017-03-22 00:55:26 -07:00
|
|
|
eina_stringshare_del(fb->source_name);
|
|
|
|
efl_unref(fb->source);
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(fb);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
Evas_Filter_Buffer *
|
|
|
|
_filter_buffer_get(Evas_Filter_Context *ctx, int bufid)
|
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *buffer;
|
|
|
|
Eina_List *l;
|
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
|
|
|
|
EINA_LIST_FOREACH(ctx->buffers, l, buffer)
|
|
|
|
if (buffer->id == bufid) return buffer;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-01-16 20:32:25 -08:00
|
|
|
void *
|
2017-03-22 00:16:22 -07:00
|
|
|
evas_filter_buffer_backing_get(Evas_Filter_Context *ctx, int bufid, Eina_Bool render)
|
2014-01-16 20:32:25 -08:00
|
|
|
{
|
2015-10-07 23:01:21 -07:00
|
|
|
Evas_Filter_Buffer *fb;
|
2014-01-16 20:32:25 -08:00
|
|
|
|
2015-10-07 23:01:21 -07:00
|
|
|
fb = _filter_buffer_get(ctx, bufid);
|
|
|
|
if (!fb) return NULL;
|
2014-03-06 16:36:16 -08:00
|
|
|
|
2017-04-02 23:34:10 -07:00
|
|
|
if (!fb->buffer)
|
|
|
|
evas_filter_buffer_backing_set(ctx, bufid, NULL);
|
|
|
|
|
2017-03-22 00:16:22 -07:00
|
|
|
if (render)
|
|
|
|
return evas_ector_buffer_render_image_get(fb->buffer); // ref++
|
|
|
|
else
|
|
|
|
return evas_ector_buffer_drawable_image_get(fb->buffer); // ref++
|
2014-01-22 21:58:05 -08:00
|
|
|
}
|
|
|
|
|
2017-04-02 23:34:10 -07:00
|
|
|
Eina_Bool
|
|
|
|
evas_filter_buffer_backing_set(Evas_Filter_Context *ctx, int bufid,
|
|
|
|
void *engine_buffer)
|
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *fb;
|
2017-04-05 03:19:36 -07:00
|
|
|
Eina_Bool ret = EINA_FALSE;
|
|
|
|
Eo *buffer = NULL;
|
2017-04-02 23:34:10 -07:00
|
|
|
|
|
|
|
fb = _filter_buffer_get(ctx, bufid);
|
|
|
|
if (!fb) return EINA_FALSE;
|
|
|
|
|
|
|
|
if (!engine_buffer)
|
|
|
|
{
|
2017-04-05 03:19:36 -07:00
|
|
|
buffer = _ector_buffer_create(fb, fb->is_render, EINA_FALSE);
|
2017-04-02 23:34:10 -07:00
|
|
|
XDBG("Allocated buffer #%d of size %ux%u %s: %p",
|
|
|
|
fb->id, fb->w, fb->h, fb->alpha_only ? "alpha" : "rgba", fb->buffer);
|
2017-04-05 03:19:36 -07:00
|
|
|
ret = buffer ? EINA_TRUE : EINA_FALSE;
|
|
|
|
goto end;
|
2017-04-02 23:34:10 -07:00
|
|
|
}
|
|
|
|
|
2017-04-05 03:19:36 -07:00
|
|
|
if (fb->is_render) goto end;
|
2017-04-02 23:34:10 -07:00
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
buffer = ENFN->ector_buffer_wrap(ENC, ctx->evas->evas, engine_buffer);
|
2017-04-05 03:19:36 -07:00
|
|
|
ret = EINA_TRUE;
|
|
|
|
|
|
|
|
end:
|
2018-10-26 03:30:28 -07:00
|
|
|
if (fb->buffer != buffer) _buffer_del((Eo *)fb->buffer);
|
2017-04-05 03:19:36 -07:00
|
|
|
fb->buffer = buffer;
|
|
|
|
return ret;
|
2017-04-02 23:34:10 -07:00
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
static Evas_Filter_Command *
|
|
|
|
_command_new(Evas_Filter_Context *ctx, Evas_Filter_Mode mode,
|
|
|
|
Evas_Filter_Buffer *input, Evas_Filter_Buffer *mask,
|
|
|
|
Evas_Filter_Buffer *output)
|
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
|
|
|
|
cmd = calloc(1, sizeof(Evas_Filter_Command));
|
|
|
|
if (!cmd) return NULL;
|
|
|
|
|
|
|
|
cmd->id = ++(ctx->last_command_id);
|
|
|
|
cmd->ctx = ctx;
|
|
|
|
cmd->mode = mode;
|
|
|
|
cmd->input = input;
|
|
|
|
cmd->mask = mask;
|
|
|
|
cmd->output = output;
|
2017-01-23 22:28:18 -08:00
|
|
|
cmd->draw.R = 255;
|
|
|
|
cmd->draw.G = 255;
|
|
|
|
cmd->draw.B = 255;
|
|
|
|
cmd->draw.A = 255;
|
|
|
|
cmd->draw.rop = EFL_GFX_RENDER_OP_BLEND;
|
2017-02-07 01:48:46 -08:00
|
|
|
if (output)
|
|
|
|
{
|
|
|
|
cmd->draw.output_was_dirty = output->dirty;
|
2017-03-22 00:55:26 -07:00
|
|
|
output->is_render = EINA_TRUE;
|
2017-02-07 01:48:46 -08:00
|
|
|
output->dirty = EINA_TRUE;
|
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
ctx->commands = eina_inlist_append(ctx->commands, EINA_INLIST_GET(cmd));
|
|
|
|
return cmd;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_command_del(Evas_Filter_Context *ctx, Evas_Filter_Command *cmd)
|
|
|
|
{
|
|
|
|
if (!ctx || !cmd) return;
|
|
|
|
ctx->commands = eina_inlist_remove(ctx->commands, EINA_INLIST_GET(cmd));
|
|
|
|
switch (cmd->mode)
|
|
|
|
{
|
2017-09-04 03:08:02 -07:00
|
|
|
case EVAS_FILTER_MODE_CURVE: _free(cmd->curve.data); break;
|
2013-12-08 22:57:50 -08:00
|
|
|
default: break;
|
|
|
|
}
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(cmd);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2013-12-31 02:38:58 -08:00
|
|
|
Evas_Filter_Buffer *
|
|
|
|
evas_filter_temporary_buffer_get(Evas_Filter_Context *ctx, int w, int h,
|
2017-01-23 00:55:17 -08:00
|
|
|
Eina_Bool alpha_only, Eina_Bool clean)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
Evas_Filter_Buffer *fb = NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
Eina_List *l;
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
EINA_LIST_FOREACH(ctx->buffers, l, fb)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
if (fb->transient && !fb->locked && (fb->alpha_only == alpha_only)
|
|
|
|
&& (!clean || !fb->dirty))
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
if ((!w || (w == fb->w)) && (!h || (h == fb->h)))
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
fb->locked = EINA_TRUE;
|
|
|
|
return fb;
|
2013-12-08 22:57:50 -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
|
|
|
if (ctx->running)
|
2014-02-06 18:22:36 -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
|
|
|
ERR("Can not create a new buffer while filter is running!");
|
2014-02-06 18:22:36 -08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
fb = _buffer_empty_new(ctx, w, h, alpha_only, EINA_TRUE);
|
|
|
|
fb->locked = EINA_TRUE;
|
2017-03-22 00:55:26 -07:00
|
|
|
fb->is_render = EINA_TRUE;
|
2017-01-23 00:55:17 -08:00
|
|
|
XDBG("Created temporary buffer %d %s", fb->id, alpha_only ? "alpha" : "rgba");
|
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
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
return fb;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_filter_buffer_unlock_all(Evas_Filter_Context *ctx)
|
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *buf = NULL;
|
|
|
|
Eina_List *l;
|
|
|
|
|
|
|
|
EINA_LIST_FOREACH(ctx->buffers, l, buf)
|
|
|
|
buf->locked = 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
|
|
|
Evas_Filter_Command *
|
2013-12-12 00:46:46 -08:00
|
|
|
evas_filter_command_fill_add(Evas_Filter_Context *ctx, void *draw_context,
|
|
|
|
int bufid)
|
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
Evas_Filter_Buffer *buf = NULL;
|
|
|
|
int R, G, B, A, cx, cy, cw, ch;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(draw_context, NULL);
|
2013-12-12 00:46:46 -08:00
|
|
|
|
|
|
|
buf = _filter_buffer_get(ctx, bufid);
|
|
|
|
if (!buf)
|
|
|
|
{
|
|
|
|
ERR("Buffer %d does not exist.", bufid);
|
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
|
|
|
return NULL;
|
2013-12-12 00:46:46 -08:00
|
|
|
}
|
|
|
|
|
2013-12-12 17:03:47 -08:00
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_FILL, buf, NULL, buf);
|
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
|
|
|
if (!cmd) return NULL;
|
2013-12-12 00:46:46 -08:00
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_color_get(ENC, draw_context, &R, &G, &B, &A);
|
2013-12-12 00:46:46 -08:00
|
|
|
DRAW_COLOR_SET(R, G, B, A);
|
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_clip_get(ENC, draw_context, &cx, &cy, &cw, &ch);
|
2013-12-12 00:46:46 -08:00
|
|
|
DRAW_CLIP_SET(cx, cy, cw, ch);
|
|
|
|
|
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
|
|
|
XDBG("Add fill %d with color(%d,%d,%d,%d)", buf->id, R, G, B, A);
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
if (!R && !G && !B && !A)
|
|
|
|
buf->dirty = 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
|
|
|
return cmd;
|
2013-12-12 00:46:46 -08:00
|
|
|
}
|
|
|
|
|
2017-02-07 01:48:46 -08:00
|
|
|
static Evas_Filter_Command *
|
|
|
|
evas_filter_command_blur_add_gl(Evas_Filter_Context *ctx,
|
|
|
|
Evas_Filter_Buffer *in, Evas_Filter_Buffer *out,
|
|
|
|
Evas_Filter_Blur_Type type,
|
2017-03-20 04:20:21 -07:00
|
|
|
int rx, int ry, int ox, int oy, int count,
|
2017-12-14 00:22:09 -08:00
|
|
|
int R, int G, int B, int A, Eina_Bool alphaonly)
|
2017-02-07 01:48:46 -08:00
|
|
|
{
|
2017-04-04 23:32:07 -07:00
|
|
|
Evas_Filter_Command *cmd = NULL;
|
2017-03-27 22:44:17 -07:00
|
|
|
Evas_Filter_Buffer *dx_in, *dx_out, *dy_in, *dy_out, *tmp = NULL;
|
2017-04-04 23:32:07 -07:00
|
|
|
int down_x = 1, down_y = 1;
|
|
|
|
int pad_x = 0, pad_y = 0;
|
2017-03-27 22:44:17 -07:00
|
|
|
double dx, dy;
|
2017-02-07 01:48:46 -08:00
|
|
|
|
|
|
|
/* GL blur implementation:
|
2017-03-20 04:20:21 -07:00
|
|
|
*
|
2017-04-04 23:32:07 -07:00
|
|
|
* - Create intermediate buffer T1, T2
|
|
|
|
* - Downscale input to buffer T1
|
|
|
|
* - Apply X blur kernel from T1 to T2
|
|
|
|
* - Apply Y blur kernel from T2 back to output
|
|
|
|
*
|
|
|
|
* In order to avoid sampling artifacts when moving or resizing a filtered
|
|
|
|
* snapshot, we make sure that we always sample and scale based on the same
|
|
|
|
* original pixels positions:
|
|
|
|
* - Input pixels must be aligned to down_x,down_y boundaries
|
|
|
|
* - T1/T2 buffer size is up to 1px larger than [input / scale_x,y]
|
2017-02-07 01:48:46 -08:00
|
|
|
*/
|
|
|
|
|
2017-03-20 04:20:21 -07:00
|
|
|
dx = rx;
|
|
|
|
dy = ry;
|
|
|
|
dx_in = in;
|
2017-03-27 22:44:17 -07:00
|
|
|
dy_out = out;
|
2017-03-20 04:20:21 -07:00
|
|
|
|
2017-04-03 05:24:07 -07:00
|
|
|
#if 1
|
2017-03-20 04:20:21 -07:00
|
|
|
if (type == EVAS_FILTER_BLUR_DEFAULT)
|
|
|
|
{
|
2017-04-04 23:32:07 -07:00
|
|
|
// Apply downscaling for large enough radii only.
|
2017-04-03 05:24:07 -07:00
|
|
|
down_x = 1 << evas_filter_smallest_pow2_larger_than(dx / 2) / 2;
|
|
|
|
down_y = 1 << evas_filter_smallest_pow2_larger_than(dy / 2) / 2;
|
2017-04-04 23:32:07 -07:00
|
|
|
|
|
|
|
// Downscaling to max 4 times for perfect picture quality (with
|
|
|
|
// the standard scaling fragment shader and SHD_SAM22).
|
2017-04-03 05:24:07 -07:00
|
|
|
if (down_x > 4) down_x = 4;
|
|
|
|
if (down_y > 4) down_y = 4;
|
2017-03-27 22:44:17 -07:00
|
|
|
|
2017-04-03 05:24:07 -07:00
|
|
|
if (down_x > 1 && down_y > 1)
|
|
|
|
{
|
2017-04-04 23:32:07 -07:00
|
|
|
int ww, hh;
|
|
|
|
|
|
|
|
pad_x = ctx->x % down_x;
|
|
|
|
pad_y = ctx->y % down_y;
|
|
|
|
|
|
|
|
ww = ceil((double) ctx->w / down_x) + 1;
|
|
|
|
hh = ceil((double) ctx->h / down_y) + 1;
|
|
|
|
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, ww, hh, in->alpha_only, EINA_TRUE);
|
2017-04-03 05:24:07 -07:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
|
2017-04-04 23:32:07 -07:00
|
|
|
dx /= (double) down_x;
|
|
|
|
dy /= (double) down_y;
|
2017-04-03 05:24:07 -07:00
|
|
|
|
|
|
|
XDBG("Add GL downscale %d (%dx%d) -> %d (%dx%d)", in->id, in->w, in->h, tmp->id, tmp->w, tmp->h);
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLEND, in, NULL, tmp);
|
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->draw.fillmode = EVAS_FILTER_FILL_MODE_STRETCH_XY;
|
2017-04-04 23:32:07 -07:00
|
|
|
cmd->draw.scale.down = EINA_TRUE;
|
|
|
|
cmd->draw.scale.pad_x = pad_x;
|
|
|
|
cmd->draw.scale.pad_y = pad_y;
|
|
|
|
cmd->draw.scale.factor_x = down_x;
|
|
|
|
cmd->draw.scale.factor_y = down_y;
|
2017-12-14 00:22:09 -08:00
|
|
|
cmd->draw.alphaonly = alphaonly;
|
2017-04-03 05:24:07 -07:00
|
|
|
dx_in = tmp;
|
|
|
|
|
2017-04-04 23:32:07 -07:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, ww, hh, in->alpha_only, EINA_TRUE);
|
2017-04-03 05:24:07 -07:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
dy_out = tmp;
|
|
|
|
}
|
2017-03-20 04:20:21 -07:00
|
|
|
}
|
2017-03-27 22:44:17 -07:00
|
|
|
#endif
|
2017-03-20 04:20:21 -07:00
|
|
|
|
2017-02-07 01:48:46 -08:00
|
|
|
if (dx && dy)
|
|
|
|
{
|
2017-03-27 22:44:17 -07:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, dx_in->w, dx_in->h, in->alpha_only, 1);
|
2017-03-20 04:20:21 -07:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
dy_in = dx_out = tmp;
|
2017-02-07 01:48:46 -08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
dx_out = out;
|
|
|
|
dy_in = in;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dx)
|
|
|
|
{
|
2017-03-27 22:44:17 -07:00
|
|
|
XDBG("Add GL blur %d -> %d (%.2fx%.2f px)", dx_in->id, dx_out->id, dx, 0.0);
|
2017-03-20 04:20:21 -07:00
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLUR, dx_in, NULL, dx_out);
|
2017-02-07 01:48:46 -08:00
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->blur.type = type;
|
|
|
|
cmd->blur.dx = dx;
|
|
|
|
cmd->blur.count = count;
|
2017-12-14 00:22:09 -08:00
|
|
|
cmd->draw.alphaonly = alphaonly;
|
2017-02-07 01:48:46 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (dy)
|
|
|
|
{
|
2017-03-27 22:44:17 -07:00
|
|
|
XDBG("Add GL blur %d -> %d (%.2fx%.2f px)", dy_in->id, dy_out->id, 0.0, dy);
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLUR, dy_in, NULL, dy_out);
|
2017-02-07 01:48:46 -08:00
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->blur.type = type;
|
|
|
|
cmd->blur.dy = dy;
|
|
|
|
cmd->blur.count = count;
|
2017-12-14 00:22:09 -08:00
|
|
|
cmd->draw.alphaonly = alphaonly;
|
2017-02-07 01:48:46 -08:00
|
|
|
}
|
|
|
|
|
2017-04-04 23:32:07 -07:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(cmd, NULL);
|
2017-03-27 22:44:17 -07:00
|
|
|
if (cmd->output != out)
|
|
|
|
{
|
|
|
|
XDBG("Add GL upscale %d (%dx%d) -> %d (%dx%d)",
|
|
|
|
cmd->output->id, cmd->output->w, cmd->output->h, out->id, out->w, out->h);
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLEND, cmd->output, NULL, out);
|
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->draw.fillmode = EVAS_FILTER_FILL_MODE_STRETCH_XY;
|
2017-04-04 23:32:07 -07:00
|
|
|
cmd->draw.scale.down = EINA_FALSE;
|
|
|
|
cmd->draw.scale.pad_x = pad_x;
|
|
|
|
cmd->draw.scale.pad_y = pad_y;
|
|
|
|
cmd->draw.scale.factor_x = down_x;
|
|
|
|
cmd->draw.scale.factor_y = down_y;
|
2017-12-14 00:22:09 -08:00
|
|
|
cmd->draw.alphaonly = alphaonly;
|
2017-03-27 22:44:17 -07:00
|
|
|
}
|
|
|
|
|
2017-02-07 01:48:46 -08:00
|
|
|
cmd->draw.ox = ox;
|
|
|
|
cmd->draw.oy = oy;
|
|
|
|
DRAW_COLOR_SET(R, G, B, A);
|
|
|
|
cmd->draw.rop = (in == out) ? EFL_GFX_RENDER_OP_COPY : EFL_GFX_RENDER_OP_BLEND;
|
|
|
|
|
|
|
|
_filter_buffer_unlock_all(ctx);
|
|
|
|
return cmd;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
ERR("Failed to add blur");
|
|
|
|
_filter_buffer_unlock_all(ctx);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Eina_Bool
|
|
|
|
_blur_support_gl(Evas_Filter_Context *ctx, Evas_Filter_Buffer *in, Evas_Filter_Buffer *out)
|
|
|
|
{
|
|
|
|
Evas_Filter_Command cmd = {};
|
|
|
|
|
|
|
|
cmd.input = in;
|
|
|
|
cmd.output = out;
|
|
|
|
cmd.mode = EVAS_FILTER_MODE_BLUR;
|
|
|
|
cmd.ctx = ctx;
|
|
|
|
cmd.blur.type = EVAS_FILTER_BLUR_GAUSSIAN;
|
|
|
|
cmd.blur.dx = 5;
|
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
return cmd.ENFN->gfx_filter_supports(_evas_engine_context(cmd.ctx->evas), &cmd) == EVAS_FILTER_SUPPORT_GL;
|
2017-02-07 01:48:46 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_blur_add(Evas_Filter_Context *ctx, void *drawctx,
|
|
|
|
int inbuf, int outbuf, Evas_Filter_Blur_Type type,
|
2017-12-14 00:22:09 -08:00
|
|
|
int dx, int dy, int ox, int oy, int count,
|
|
|
|
Eina_Bool alphaonly)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *in = NULL, *out = NULL, *tmp = NULL, *in_dy = NULL;
|
|
|
|
Evas_Filter_Buffer *out_dy = NULL, *out_dx = NULL;
|
2017-01-23 00:55:17 -08:00
|
|
|
Evas_Filter_Buffer *copybuf = NULL, *blendbuf = NULL;
|
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
|
|
|
Evas_Filter_Command *cmd = NULL;
|
2017-01-23 00:55:17 -08:00
|
|
|
int R, G, B, A, render_op;
|
|
|
|
Eina_Bool override;
|
|
|
|
DATA32 color;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(drawctx, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2014-03-11 02:21:46 -07:00
|
|
|
if (dx < 0) dx = 0;
|
|
|
|
if (dy < 0) dy = 0;
|
2014-03-20 20:04:35 -07:00
|
|
|
if (!dx && !dy)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Changing 0px blur into simple blend");
|
2017-12-14 00:22:09 -08:00
|
|
|
return evas_filter_command_blend_add(ctx, drawctx, inbuf, outbuf, ox, oy, EVAS_FILTER_FILL_MODE_NONE, alphaonly);
|
2014-03-20 20:04:35 -07:00
|
|
|
}
|
2014-03-11 02:21:46 -07:00
|
|
|
|
2014-03-11 21:55:44 -07:00
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
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
|
|
|
EINA_SAFETY_ON_FALSE_GOTO(in, fail);
|
2014-03-11 21:55:44 -07:00
|
|
|
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
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
|
|
|
EINA_SAFETY_ON_FALSE_GOTO(out, fail);
|
2014-03-11 21:55:44 -07:00
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_color_get(ENC, drawctx, &R, &G, &B, &A);
|
2015-06-12 00:44:43 -07:00
|
|
|
color = ARGB_JOIN(A, R, G, B);
|
|
|
|
if (!color)
|
|
|
|
{
|
|
|
|
DBG("Blur with transparent color. Nothing to do.");
|
2017-01-23 00:55:17 -08:00
|
|
|
return _command_new(ctx, EVAS_FILTER_MODE_SKIP, NULL, NULL, NULL);
|
2015-06-12 00:44:43 -07:00
|
|
|
}
|
|
|
|
|
2017-02-07 01:48:46 -08:00
|
|
|
if (_blur_support_gl(ctx, in, out))
|
2017-12-14 00:22:09 -08:00
|
|
|
return evas_filter_command_blur_add_gl(ctx, in, out, type, dx, dy, ox, oy,
|
|
|
|
count, R, G, B, A, alphaonly);
|
2017-01-25 01:06:29 -08:00
|
|
|
|
|
|
|
// Note (SW engine):
|
|
|
|
// The basic blur operation overrides the pixels in the target buffer,
|
|
|
|
// only supports one direction (X or Y) and no offset. As a consequence
|
|
|
|
// most cases require intermediate work buffers.
|
|
|
|
|
|
|
|
if (in == out) out->dirty = EINA_FALSE;
|
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
render_op = ENFN->context_render_op_get(ENC, drawctx);
|
2017-01-23 00:55:17 -08:00
|
|
|
override = (render_op == EVAS_RENDER_COPY);
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
switch (type)
|
|
|
|
{
|
2014-03-11 02:21:46 -07:00
|
|
|
case EVAS_FILTER_BLUR_GAUSSIAN:
|
|
|
|
count = 1;
|
|
|
|
break;
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
case EVAS_FILTER_BLUR_BOX:
|
2014-03-11 02:21:46 -07:00
|
|
|
count = MIN(MAX(1, count), 6);
|
2013-12-08 22:57:50 -08:00
|
|
|
break;
|
2014-03-11 02:21:46 -07:00
|
|
|
|
|
|
|
case EVAS_FILTER_BLUR_DEFAULT:
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
/* In DEFAULT mode we cheat, depending on the size of the kernel:
|
|
|
|
* For 1px to 2px, use true Gaussian blur.
|
|
|
|
* For 3px to 6px, use two Box blurs.
|
|
|
|
* For more than 6px, use three Box blurs.
|
|
|
|
* This will give both nicer and MUCH faster results than Gaussian.
|
|
|
|
*
|
|
|
|
* NOTE: This step should be avoided in GL.
|
|
|
|
*/
|
|
|
|
|
2014-03-11 02:21:46 -07:00
|
|
|
int tmp_out = outbuf;
|
|
|
|
int tmp_in = inbuf;
|
|
|
|
int tmp_ox = ox;
|
|
|
|
int tmp_oy = oy;
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
// For 2D blur: create intermediate buffer
|
2014-03-11 02:21:46 -07:00
|
|
|
if (dx && dy)
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 1);
|
2014-03-11 02:21:46 -07:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
tmp_in = tmp_out = tmp->id;
|
|
|
|
tmp_ox = tmp_oy = 0;
|
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
// X box blur
|
2014-03-11 02:21:46 -07:00
|
|
|
if (dx)
|
|
|
|
{
|
|
|
|
if (dx <= 2)
|
|
|
|
type = EVAS_FILTER_BLUR_GAUSSIAN;
|
|
|
|
else
|
2017-01-23 00:55:17 -08:00
|
|
|
type = EVAS_FILTER_BLUR_BOX;
|
2014-03-11 02:21:46 -07:00
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
if (dy) ENFN->context_color_set(ENC, drawctx, 255, 255, 255, 255);
|
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
|
|
|
cmd = evas_filter_command_blur_add(ctx, drawctx, inbuf, tmp_out,
|
2017-12-14 00:22:09 -08:00
|
|
|
type, dx, 0, tmp_ox, tmp_oy, 0,
|
|
|
|
alphaonly);
|
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
|
|
|
if (!cmd) goto fail;
|
2014-03-11 02:21:46 -07:00
|
|
|
cmd->blur.auto_count = EINA_TRUE;
|
2017-08-25 10:51:31 -07:00
|
|
|
if (dy) ENFN->context_color_set(ENC, drawctx, R, G, B, A);
|
2014-03-11 02:21:46 -07:00
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
// Y box blur
|
2014-03-11 02:21:46 -07:00
|
|
|
if (dy)
|
|
|
|
{
|
|
|
|
if (dy <= 2)
|
|
|
|
type = EVAS_FILTER_BLUR_GAUSSIAN;
|
|
|
|
else
|
|
|
|
type = EVAS_FILTER_BLUR_BOX;
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
if (dx && (inbuf == outbuf))
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_render_op_set(ENC, drawctx, EVAS_RENDER_COPY);
|
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
|
|
|
cmd = evas_filter_command_blur_add(ctx, drawctx, tmp_in, outbuf,
|
2017-12-14 00:22:09 -08:00
|
|
|
type, 0, dy, ox, oy, 0,
|
|
|
|
alphaonly);
|
2017-01-23 00:55:17 -08:00
|
|
|
if (dx && (inbuf == outbuf))
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_render_op_set(ENC, drawctx, render_op);
|
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
|
|
|
if (!cmd) goto fail;
|
2014-03-11 02:21:46 -07:00
|
|
|
cmd->blur.auto_count = EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
return cmd;
|
2014-03-11 02:21:46 -07:00
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
default:
|
2013-12-29 22:43:52 -08:00
|
|
|
CRI("Not implemented yet!");
|
2013-12-08 22:57:50 -08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
// For 2D blur: create intermediate buffer between X and Y passes
|
2013-12-08 22:57:50 -08:00
|
|
|
if (dx && dy)
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
// If there's an offset: create intermediate buffer before offset blend
|
|
|
|
if (ox || oy)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
copybuf = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
2014-02-13 19:45:55 -08:00
|
|
|
if (!copybuf) goto fail;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
// Intermediate buffer between X and Y passes
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
|
|
|
if (!tmp) goto fail;
|
|
|
|
|
|
|
|
if (in == out)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
// IN = OUT and 2-D blur. IN -blur-> TMP -blur-> IN.
|
|
|
|
out_dx = tmp;
|
|
|
|
in_dy = tmp;
|
|
|
|
out_dy = copybuf ? copybuf : in;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// IN != OUT and 2-D blur. IN -blur-> TMP -blur-> OUT.
|
|
|
|
out_dx = tmp;
|
|
|
|
in_dy = tmp;
|
2017-01-23 00:55:17 -08:00
|
|
|
out_dy = copybuf ? copybuf : out;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (dx)
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
// X blur only
|
|
|
|
if (in == out)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
// IN = OUT and 1-D blur. IN -blur-> TMP -copy-> IN.
|
2017-01-23 00:55:17 -08:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
2013-12-08 22:57:50 -08:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
copybuf = tmp;
|
|
|
|
out_dx = tmp;
|
|
|
|
}
|
2017-01-23 00:55:17 -08:00
|
|
|
else if (ox || oy || (color != 0xFFFFFFFF))
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> TMP -blend-> OUT.
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
|
|
|
if (!tmp) goto fail;
|
|
|
|
blendbuf = tmp;
|
|
|
|
out_dx = tmp;
|
|
|
|
}
|
|
|
|
else if (out->dirty)
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> TMP -blend-> OUT.
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
|
|
|
if (!tmp) goto fail;
|
|
|
|
blendbuf = tmp;
|
|
|
|
out_dx = tmp;
|
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
else
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> OUT.
|
2017-01-23 00:55:17 -08:00
|
|
|
out_dx = out;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
// Y blur only
|
|
|
|
if (in == out)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
// IN = OUT and 1-D blur. IN -blur-> TMP -copy-> IN.
|
2017-01-23 00:55:17 -08:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
2013-12-08 22:57:50 -08:00
|
|
|
if (!tmp) goto fail;
|
|
|
|
copybuf = tmp;
|
|
|
|
in_dy = in;
|
|
|
|
out_dy = tmp;
|
|
|
|
}
|
2017-01-23 00:55:17 -08:00
|
|
|
else if (ox || oy || (color != 0xFFFFFFFF))
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> TMP -blend-> IN.
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
|
|
|
if (!tmp) goto fail;
|
|
|
|
if (override)
|
|
|
|
copybuf = tmp;
|
|
|
|
else
|
|
|
|
blendbuf = tmp;
|
|
|
|
in_dy = in;
|
|
|
|
out_dy = tmp;
|
|
|
|
}
|
|
|
|
else if (out->dirty && !override)
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> TMP -blend-> OUT.
|
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, 0, 0, in->alpha_only, 0);
|
|
|
|
if (!tmp) goto fail;
|
|
|
|
blendbuf = tmp;
|
|
|
|
in_dy = in;
|
|
|
|
out_dy = tmp;
|
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
else
|
|
|
|
{
|
|
|
|
// IN != OUT and 1-D blur. IN -blur-> OUT.
|
|
|
|
in_dy = in;
|
2017-01-23 00:55:17 -08:00
|
|
|
out_dy = out;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dx)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Add horizontal blur %d -> %d (%dpx)", in->id, out_dx->id, dx);
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLUR, in, NULL, out_dx);
|
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->blur.type = type;
|
|
|
|
cmd->blur.dx = dx;
|
|
|
|
cmd->blur.dy = 0;
|
2014-03-11 02:21:46 -07:00
|
|
|
cmd->blur.count = count;
|
2017-01-23 00:55:17 -08:00
|
|
|
if (!dy) DRAW_COLOR_SET(R, G, B, A);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (dy)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Add vertical blur %d -> %d (%dpx)", in_dy->id, out_dy->id, dy);
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLUR, in_dy, NULL, out_dy);
|
|
|
|
if (!cmd) goto fail;
|
|
|
|
cmd->blur.type = type;
|
|
|
|
cmd->blur.dx = 0;
|
|
|
|
cmd->blur.dy = dy;
|
2014-03-11 02:21:46 -07:00
|
|
|
cmd->blur.count = count;
|
2017-01-23 00:55:17 -08:00
|
|
|
DRAW_COLOR_SET(R, G, B, A);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
if (blendbuf)
|
|
|
|
{
|
|
|
|
Evas_Filter_Command *blendcmd;
|
|
|
|
|
|
|
|
XDBG("Add extra blend %d -> %d", blendbuf->id, out->id);
|
|
|
|
blendcmd = evas_filter_command_blend_add(ctx, drawctx,
|
|
|
|
blendbuf->id, out->id, ox, oy,
|
2017-12-14 00:22:09 -08:00
|
|
|
EVAS_FILTER_FILL_MODE_NONE,
|
|
|
|
alphaonly);
|
2017-01-23 00:55:17 -08:00
|
|
|
if (!blendcmd) goto fail;
|
|
|
|
ox = oy = 0;
|
|
|
|
}
|
|
|
|
else if (copybuf)
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *copycmd;
|
2014-03-10 23:11:21 -07:00
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
XDBG("Add extra copy %d -> %d: offset: %d,%d", copybuf->id, out->id, ox, oy);
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_color_set(ENC, drawctx, 255, 255, 255, 255);
|
|
|
|
ENFN->context_render_op_set(ENC, drawctx, EVAS_RENDER_COPY);
|
2017-01-23 00:55:17 -08:00
|
|
|
copycmd = evas_filter_command_blend_add(ctx, drawctx,
|
|
|
|
copybuf->id, out->id, ox, oy,
|
2017-12-14 00:22:09 -08:00
|
|
|
EVAS_FILTER_FILL_MODE_NONE,
|
|
|
|
alphaonly);
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_color_set(ENC, drawctx, R, G, B, A);
|
|
|
|
ENFN->context_render_op_set(ENC, drawctx, render_op);
|
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
|
|
|
if (!copycmd) goto fail;
|
2014-02-19 03:03:20 -08:00
|
|
|
ox = oy = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2014-03-20 20:20:11 -07:00
|
|
|
out->dirty = EINA_TRUE;
|
2013-12-08 22:57:50 -08:00
|
|
|
_filter_buffer_unlock_all(ctx);
|
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
|
|
|
return cmd;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
fail:
|
|
|
|
ERR("Failed to add blur");
|
|
|
|
_filter_buffer_unlock_all(ctx);
|
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
|
|
|
return NULL;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_blend_add(Evas_Filter_Context *ctx, void *drawctx,
|
2013-12-31 00:51:09 -08:00
|
|
|
int inbuf, int outbuf, int ox, int oy,
|
2017-12-14 00:22:09 -08:00
|
|
|
Evas_Filter_Fill_Mode fillmode,
|
|
|
|
Eina_Bool alphaonly)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
Evas_Filter_Buffer *in, *out;
|
2017-01-23 00:55:17 -08:00
|
|
|
Eina_Bool copy;
|
2013-12-08 22:57:50 -08:00
|
|
|
int R, G, B, A;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (inbuf == outbuf)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Skipping NOP blend operation %d --> %d", inbuf, outbuf);
|
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
|
|
|
return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
if (!in)
|
|
|
|
{
|
|
|
|
ERR("Buffer %d does not exist [input].", inbuf);
|
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
|
|
|
return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
|
|
|
if (!out)
|
|
|
|
{
|
|
|
|
ERR("Buffer %d does not exist [output].", outbuf);
|
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
|
|
|
return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BLEND, in, NULL, out);
|
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
|
|
|
if (!cmd) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
if (ENFN->context_render_op_get(ENC, drawctx) == EVAS_RENDER_COPY)
|
2017-01-23 00:55:17 -08:00
|
|
|
copy = EINA_TRUE;
|
|
|
|
else
|
|
|
|
copy = EINA_FALSE;
|
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
ENFN->context_color_get(ENC, drawctx, &R, &G, &B, &A);
|
2013-12-08 22:57:50 -08:00
|
|
|
DRAW_COLOR_SET(R, G, B, A);
|
2013-12-31 00:51:09 -08:00
|
|
|
DRAW_FILL_SET(fillmode);
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd->draw.ox = ox;
|
|
|
|
cmd->draw.oy = oy;
|
2017-01-23 00:55:17 -08:00
|
|
|
cmd->draw.rop = copy ? EFL_GFX_RENDER_OP_COPY : EFL_GFX_RENDER_OP_BLEND;
|
2017-12-14 00:22:09 -08:00
|
|
|
cmd->draw.alphaonly = alphaonly;
|
2014-01-02 22:51:17 -08:00
|
|
|
cmd->draw.clip_use =
|
2017-12-14 00:22:09 -08:00
|
|
|
!!ENFN->context_clip_get(ENC, drawctx,
|
|
|
|
&cmd->draw.clip.x, &cmd->draw.clip.y,
|
|
|
|
&cmd->draw.clip.w, &cmd->draw.clip.h);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
XDBG("Add %s %d -> %d: offset %d,%d, color: %d,%d,%d,%d",
|
|
|
|
copy ? "copy" : "blend", in->id, out->id, ox, oy, R, G, B, A);
|
2014-01-22 23:54:50 -08:00
|
|
|
if (cmd->draw.clip_use)
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Draw clip: %d,%d,%d,%d", cmd->draw.clip.x, cmd->draw.clip.y,
|
2014-01-22 23:54:50 -08:00
|
|
|
cmd->draw.clip.w, cmd->draw.clip.h);
|
|
|
|
|
2014-03-20 20:20:11 -07:00
|
|
|
out->dirty = EINA_TRUE;
|
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
|
|
|
return cmd;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_grow_add(Evas_Filter_Context *ctx, void *draw_context,
|
2017-12-14 00:22:09 -08:00
|
|
|
int inbuf, int outbuf, int radius, Eina_Bool smooth,
|
|
|
|
Eina_Bool alphaonly)
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *blurcmd, *threshcmd, *blendcmd;
|
|
|
|
Evas_Filter_Buffer *tmp = NULL, *in, *out;
|
2013-12-08 22:57:50 -08:00
|
|
|
int diam = abs(radius) * 2 + 1;
|
|
|
|
DATA8 curve[256] = {0};
|
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
|
|
|
int tmin = 0, growbuf;
|
2013-12-08 22:57:50 -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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2014-03-20 20:04:35 -07:00
|
|
|
if (!radius)
|
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Changing 0px grow into simple blend");
|
2017-12-14 00:22:09 -08:00
|
|
|
return evas_filter_command_blend_add(ctx, draw_context, inbuf, outbuf, 0, 0,
|
|
|
|
EVAS_FILTER_FILL_MODE_NONE, alphaonly);
|
2014-03-20 20:04:35 -07:00
|
|
|
}
|
|
|
|
|
2014-02-19 02:38:58 -08:00
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
2014-02-19 02:38:58 -08:00
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
|
|
|
|
|
|
|
if ((inbuf != outbuf) && out->dirty)
|
2014-02-19 02:38:58 -08:00
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, in->w, in->h, in->alpha_only, 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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(tmp, NULL);
|
2014-02-19 02:38:58 -08:00
|
|
|
growbuf = tmp->id;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
growbuf = outbuf;
|
|
|
|
|
|
|
|
blurcmd = evas_filter_command_blur_add(ctx, draw_context, inbuf, growbuf,
|
2013-12-08 22:57:50 -08:00
|
|
|
EVAS_FILTER_BLUR_DEFAULT,
|
2017-12-14 00:22:09 -08:00
|
|
|
abs(radius), abs(radius), 0, 0, 0,
|
|
|
|
alphaonly);
|
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
|
|
|
if (!blurcmd) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (diam > 255) diam = 255;
|
|
|
|
if (radius > 0)
|
|
|
|
tmin = 255 / diam;
|
|
|
|
else if (radius < 0)
|
|
|
|
tmin = 256 - (255 / diam);
|
|
|
|
|
|
|
|
if (!smooth)
|
|
|
|
memset(curve + tmin, 255, 256 - tmin);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
int k, start, end, range;
|
|
|
|
|
|
|
|
// This is pretty experimental.
|
|
|
|
range = MAX(2, 12 - radius);
|
|
|
|
start = ((tmin > range) ? (tmin - range) : 0);
|
|
|
|
end = ((tmin < (256 - range)) ? (tmin + range) : 256);
|
|
|
|
|
|
|
|
for (k = start; k < end; k++)
|
|
|
|
curve[k] = ((k - start) * 255) / (end - start);
|
|
|
|
if (end < 256)
|
|
|
|
memset(curve + end, 255, 256 - end);
|
|
|
|
}
|
|
|
|
|
2014-02-19 02:38:58 -08:00
|
|
|
threshcmd = evas_filter_command_curve_add(ctx, draw_context, growbuf, growbuf,
|
2013-12-08 22:57:50 -08:00
|
|
|
curve, EVAS_FILTER_CHANNEL_ALPHA);
|
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
|
|
|
if (!threshcmd)
|
2013-12-08 22:57:50 -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
|
|
|
_command_del(ctx, blurcmd);
|
|
|
|
return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2014-02-19 02:38:58 -08:00
|
|
|
if (tmp)
|
|
|
|
{
|
|
|
|
blendcmd = evas_filter_command_blend_add(ctx, draw_context, tmp->id,
|
|
|
|
outbuf, 0, 0,
|
2017-12-14 00:22:09 -08:00
|
|
|
EVAS_FILTER_FILL_MODE_NONE,
|
|
|
|
alphaonly);
|
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
|
|
|
if (!blendcmd)
|
2014-02-19 02:38:58 -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
|
|
|
_command_del(ctx, threshcmd);
|
|
|
|
_command_del(ctx, blurcmd);
|
|
|
|
return NULL;
|
2014-02-19 02:38:58 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
return blurcmd;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_curve_add(Evas_Filter_Context *ctx,
|
|
|
|
void *draw_context EINA_UNUSED,
|
|
|
|
int inbuf, int outbuf, DATA8 *curve,
|
|
|
|
Evas_Filter_Channel channel)
|
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
Evas_Filter_Buffer *in, *out;
|
|
|
|
DATA8 *copy;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(curve, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (in->alpha_only != out->alpha_only)
|
2015-12-10 22:44:48 -08:00
|
|
|
WRN("Incompatible formats for color curves, implicit conversion will be "
|
|
|
|
"slow and may not produce the desired output.");
|
2013-12-08 22:57:50 -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
|
|
|
XDBG("Add curve %d -> %d", in->id, out->id);
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
copy = malloc(256 * sizeof(DATA8));
|
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
|
|
|
if (!copy) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_CURVE, in, NULL, out);
|
2014-02-13 01:57:01 -08:00
|
|
|
if (!cmd)
|
|
|
|
{
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(copy);
|
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
|
|
|
return NULL;
|
2014-02-13 01:57:01 -08:00
|
|
|
}
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
memcpy(copy, curve, 256 * sizeof(DATA8));
|
|
|
|
cmd->curve.data = copy;
|
2017-01-23 22:28:18 -08:00
|
|
|
if (cmd->input->alpha_only)
|
|
|
|
cmd->curve.channel = EVAS_FILTER_CHANNEL_ALPHA;
|
|
|
|
else
|
|
|
|
cmd->curve.channel = channel;
|
2013-12-08 22:57:50 -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
|
|
|
return cmd;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_displacement_map_add(Evas_Filter_Context *ctx,
|
|
|
|
void *draw_context EINA_UNUSED,
|
|
|
|
int inbuf, int outbuf, int dispbuf,
|
|
|
|
Evas_Filter_Displacement_Flags flags,
|
2013-12-31 00:51:09 -08:00
|
|
|
int intensity,
|
|
|
|
Evas_Filter_Fill_Mode fillmode)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Buffer *in, *out, *map, *tmp = NULL, *disp_out;
|
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
|
|
|
Evas_Filter_Command *cmd = NULL;
|
2017-12-14 00:22:09 -08:00
|
|
|
Eina_Bool alphaonly = EINA_FALSE;
|
2013-12-08 22:57:50 -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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(intensity >= 0, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
|
|
|
map = _filter_buffer_get(ctx, dispbuf);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(map, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (in->alpha_only != out->alpha_only)
|
2015-12-10 22:44:48 -08:00
|
|
|
DBG("Different color formats, implicit conversion may be slow");
|
|
|
|
|
|
|
|
if (map->alpha_only)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2015-12-10 22:44:48 -08:00
|
|
|
WRN("Displacement map is not an RGBA buffer, X and Y axes will be "
|
|
|
|
"displaced together.");
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (in == out)
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
tmp = evas_filter_temporary_buffer_get(ctx, in->w, in->h, in->alpha_only, 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
|
|
|
if (!tmp) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
disp_out = tmp;
|
|
|
|
}
|
|
|
|
else disp_out = out;
|
|
|
|
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_DISPLACE, in, map, disp_out);
|
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
|
|
|
if (!cmd) goto fail;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2013-12-31 00:51:09 -08:00
|
|
|
DRAW_FILL_SET(fillmode);
|
2014-01-06 17:16:39 -08:00
|
|
|
cmd->displacement.flags = flags & EVAS_FILTER_DISPLACE_BITMASK;
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd->displacement.intensity = intensity;
|
2017-08-25 10:51:31 -07:00
|
|
|
cmd->draw.rop = _evas_to_gfx_render_op(ENFN->context_render_op_get(ENC, draw_context));
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
if (tmp)
|
|
|
|
{
|
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
|
|
|
Evas_Filter_Command *fillcmd;
|
|
|
|
|
|
|
|
fillcmd = evas_filter_command_blend_add(ctx, draw_context, disp_out->id,
|
|
|
|
out->id, 0, 0,
|
2017-12-14 00:22:09 -08:00
|
|
|
EVAS_FILTER_FILL_MODE_NONE,
|
|
|
|
alphaonly);
|
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
|
|
|
if (!fillcmd) goto fail;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
_filter_buffer_unlock_all(ctx);
|
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
|
|
|
return cmd;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
_filter_buffer_unlock_all(ctx);
|
|
|
|
_command_del(ctx, cmd);
|
|
|
|
return NULL;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_mask_add(Evas_Filter_Context *ctx, void *draw_context,
|
2013-12-31 00:51:09 -08:00
|
|
|
int inbuf, int maskbuf, int outbuf,
|
|
|
|
Evas_Filter_Fill_Mode fillmode)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
Evas_Filter_Buffer *in, *out, *mask;
|
2015-12-03 22:09:56 -08:00
|
|
|
Efl_Gfx_Render_Op render_op;
|
2013-12-08 22:57:50 -08:00
|
|
|
int R, G, B, A;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-08-25 10:51:31 -07:00
|
|
|
render_op = _evas_to_gfx_render_op(ENFN->context_render_op_get(ENC, draw_context));
|
|
|
|
ENFN->context_color_get(ENC, draw_context, &R, &G, &B, &A);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
|
|
|
mask = _filter_buffer_get(ctx, maskbuf);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(mask, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_MASK, in, mask, out);
|
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
|
|
|
if (!cmd) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2015-12-03 22:09:56 -08:00
|
|
|
cmd->draw.rop = render_op;
|
2013-12-08 22:57:50 -08:00
|
|
|
DRAW_COLOR_SET(R, G, B, A);
|
2013-12-31 00:51:09 -08:00
|
|
|
DRAW_FILL_SET(fillmode);
|
2013-12-08 22:57:50 -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
|
|
|
return cmd;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2013-12-08 22:57:50 -08:00
|
|
|
evas_filter_command_bump_map_add(Evas_Filter_Context *ctx,
|
|
|
|
void *draw_context EINA_UNUSED,
|
|
|
|
int inbuf, int bumpbuf, int outbuf,
|
|
|
|
float xyangle, float zangle, float elevation,
|
|
|
|
float sf,
|
|
|
|
DATA32 black, DATA32 color, DATA32 white,
|
2013-12-31 00:51:09 -08:00
|
|
|
Evas_Filter_Bump_Flags flags,
|
|
|
|
Evas_Filter_Fill_Mode fillmode)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
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
|
|
|
Evas_Filter_Buffer *in, *out, *map;
|
2013-12-08 22:57:50 -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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
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 = _filter_buffer_get(ctx, bumpbuf);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(map, NULL);
|
2013-12-08 22:57:50 -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
|
|
|
if (!map->alpha_only)
|
2015-12-10 22:44:48 -08:00
|
|
|
DBG("Bump map is not an Alpha buffer, implicit conversion may be slow");
|
|
|
|
|
|
|
|
// FIXME: Boo!
|
|
|
|
if (!in->alpha_only)
|
|
|
|
WRN("RGBA bump map support is not implemented! This will trigger conversion.");
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
// FIXME: Must ensure in != out
|
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
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(in != out, NULL);
|
|
|
|
EINA_SAFETY_ON_FALSE_RETURN_VAL(map != out, NULL);
|
2013-12-08 22:57:50 -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
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_BUMP, in, map, out);
|
|
|
|
if (!cmd) return NULL;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2013-12-31 00:51:09 -08:00
|
|
|
DRAW_FILL_SET(fillmode);
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd->bump.xyangle = xyangle;
|
|
|
|
cmd->bump.zangle = zangle;
|
|
|
|
cmd->bump.specular_factor = sf;
|
|
|
|
cmd->bump.dark = black;
|
|
|
|
cmd->bump.color = color;
|
|
|
|
cmd->bump.white = white;
|
|
|
|
cmd->bump.elevation = elevation;
|
|
|
|
cmd->bump.compensate = !!(flags & EVAS_FILTER_BUMP_COMPENSATE);
|
2014-03-20 20:20:11 -07: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
|
|
|
return cmd;
|
2013-12-08 22:57:50 -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
|
|
|
Evas_Filter_Command *
|
2014-01-07 01:38:22 -08:00
|
|
|
evas_filter_command_transform_add(Evas_Filter_Context *ctx,
|
|
|
|
void *draw_context EINA_UNUSED,
|
2014-01-06 23:44:10 -08:00
|
|
|
int inbuf, int outbuf,
|
2014-01-07 01:38:22 -08:00
|
|
|
Evas_Filter_Transform_Flags flags,
|
|
|
|
int ox, int oy)
|
2014-01-06 23:44:10 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
|
|
|
Evas_Filter_Buffer *in, *out;
|
|
|
|
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, NULL);
|
2014-01-06 23:44:10 -08:00
|
|
|
|
|
|
|
in = _filter_buffer_get(ctx, inbuf);
|
|
|
|
out = _filter_buffer_get(ctx, outbuf);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(in, NULL);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(out, NULL);
|
2014-01-06 23:44:10 -08:00
|
|
|
|
|
|
|
cmd = _command_new(ctx, EVAS_FILTER_MODE_TRANSFORM, in, NULL, out);
|
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
|
|
|
if (!cmd) return NULL;
|
2014-01-06 23:44:10 -08:00
|
|
|
|
2016-01-21 21:06:57 -08:00
|
|
|
DRAW_COLOR_SET(255, 255, 255, 255);
|
2014-01-06 23:44:10 -08:00
|
|
|
cmd->transform.flags = flags;
|
2014-01-07 01:38:22 -08:00
|
|
|
cmd->draw.ox = ox;
|
|
|
|
cmd->draw.oy = oy;
|
2014-01-06 23:44:10 -08:00
|
|
|
|
2016-01-21 21:06:57 -08:00
|
|
|
if (in->alpha_only == out->alpha_only)
|
|
|
|
{
|
|
|
|
DBG("Incompatible buffer formats, will trigger implicit conversion.");
|
|
|
|
cmd->draw.rop = EFL_GFX_RENDER_OP_COPY;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
cmd->draw.rop = EFL_GFX_RENDER_OP_BLEND;
|
|
|
|
|
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
|
|
|
return cmd;
|
2014-01-06 23:44:10 -08:00
|
|
|
}
|
|
|
|
|
2017-03-14 22:49:50 -07:00
|
|
|
void
|
|
|
|
evas_filter_context_obscured_region_set(Evas_Filter_Context *ctx, Eina_Rectangle rect)
|
|
|
|
{
|
|
|
|
ctx->obscured.real = rect;
|
|
|
|
}
|
|
|
|
|
2014-01-16 22:05:23 -08:00
|
|
|
/* Final target */
|
|
|
|
Eina_Bool
|
|
|
|
evas_filter_target_set(Evas_Filter_Context *ctx, void *draw_context,
|
2017-04-03 22:28:29 -07:00
|
|
|
void *surface, int x, int y, const RGBA_Map *map)
|
2014-01-16 22:05:23 -08:00
|
|
|
{
|
2015-08-31 01:28:58 -07:00
|
|
|
void *mask = NULL;
|
|
|
|
|
2014-01-16 22:05:23 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx, EINA_FALSE);
|
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
ctx->target.surface = ENFN->image_ref(ENC, surface);
|
2014-03-02 01:39:08 -08:00
|
|
|
ctx->target.x = x;
|
|
|
|
ctx->target.y = y;
|
|
|
|
ctx->target.clip_use = ENFN->context_clip_get
|
2017-08-25 10:51:31 -07:00
|
|
|
(ENC, draw_context, &ctx->target.cx, &ctx->target.cy,
|
2014-03-02 01:39:08 -08:00
|
|
|
&ctx->target.cw, &ctx->target.ch);
|
2014-06-10 23:59:31 -07:00
|
|
|
ctx->target.color_use = ENFN->context_multiplier_get
|
2017-08-25 10:51:31 -07:00
|
|
|
(ENC, draw_context, &ctx->target.r, &ctx->target.g,
|
2014-06-10 23:59:31 -07:00
|
|
|
&ctx->target.b, &ctx->target.a);
|
|
|
|
if (ctx->target.r == 255 && ctx->target.g == 255 &&
|
|
|
|
ctx->target.b == 255 && ctx->target.a == 255)
|
|
|
|
ctx->target.color_use = EINA_FALSE;
|
2017-08-25 10:51:31 -07:00
|
|
|
ctx->target.rop = ENFN->context_render_op_get(ENC, draw_context);
|
2014-03-02 01:39:08 -08:00
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(ctx->target.map);
|
2017-04-03 22:28:29 -07:00
|
|
|
if (!map) ctx->target.map = NULL;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
size_t len = sizeof(RGBA_Map) + sizeof(RGBA_Map_Point) * (map->count - 1);
|
|
|
|
ctx->target.map = malloc(len);
|
|
|
|
memcpy(ctx->target.map, map, len);
|
|
|
|
}
|
|
|
|
|
2014-11-12 17:31:41 -08:00
|
|
|
ENFN->context_clip_image_get
|
2017-08-25 10:51:31 -07:00
|
|
|
(ENC, draw_context, &mask, &ctx->target.mask_x, &ctx->target.mask_y);
|
2015-08-31 01:28:58 -07:00
|
|
|
if (ctx->target.mask)
|
2017-04-24 15:09:25 -07:00
|
|
|
ctx->evas->engine.func->image_free(_evas_engine_context(ctx->evas), ctx->target.mask);
|
2017-04-03 22:28:29 -07:00
|
|
|
ctx->target.mask = mask; // FIXME: why no ref???
|
2014-11-12 17:31:41 -08:00
|
|
|
|
2014-01-16 22:05:23 -08:00
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Eina_Bool
|
2017-08-25 10:51:53 -07:00
|
|
|
_filter_target_render(void *engine, void *output, Evas_Filter_Context *ctx)
|
2014-01-16 22:05: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
|
|
|
Evas_Filter_Buffer *src;
|
|
|
|
void *drawctx, *image = NULL, *surface;
|
|
|
|
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(ctx->target.surface, EINA_FALSE);
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
drawctx = ENFN->context_new(engine);
|
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
|
|
|
surface = ctx->target.surface;
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2014-02-03 19:32:15 -08:00
|
|
|
src = _filter_buffer_get(ctx, EVAS_FILTER_BUFFER_OUTPUT_ID);
|
2014-03-02 01:39:08 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(src, EINA_FALSE);
|
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
image = evas_ector_buffer_drawable_image_get(src->buffer);
|
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
|
|
|
EINA_SAFETY_ON_NULL_GOTO(image, fail);
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2015-12-08 17:45:53 -08:00
|
|
|
// FIXME: Use ector buffer RENDERER here
|
|
|
|
|
2014-03-02 01:39:08 -08:00
|
|
|
if (ctx->target.clip_use)
|
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->context_clip_set(engine, drawctx, ctx->target.cx, ctx->target.cy,
|
2014-03-02 01:39:08 -08:00
|
|
|
ctx->target.cw, ctx->target.ch);
|
|
|
|
}
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2014-06-10 23:59:31 -07:00
|
|
|
if (ctx->target.color_use)
|
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->context_multiplier_set(engine, drawctx,
|
2014-06-10 23:59:31 -07:00
|
|
|
ctx->target.r, ctx->target.g,
|
|
|
|
ctx->target.b, ctx->target.a);
|
|
|
|
}
|
|
|
|
|
2014-11-12 17:31:41 -08:00
|
|
|
if (ctx->target.mask)
|
2016-12-22 02:41:04 -08:00
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->context_clip_image_set(engine, drawctx, ctx->target.mask,
|
2016-12-22 02:41:04 -08:00
|
|
|
ctx->target.mask_x, ctx->target.mask_y,
|
|
|
|
ctx->evas, EINA_FALSE);
|
|
|
|
}
|
2014-11-12 17:31:41 -08:00
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->context_render_op_set(engine, drawctx, ctx->target.rop);
|
2017-04-03 22:28:29 -07:00
|
|
|
if (ctx->target.map)
|
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->image_map_draw(engine, output, drawctx, surface, image,
|
2017-04-03 22:28:29 -07:00
|
|
|
ctx->target.map, EINA_TRUE, 0, EINA_FALSE);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->image_draw(engine, output, drawctx, surface, image,
|
2017-04-03 22:28:29 -07:00
|
|
|
0, 0, src->w, src->h,
|
|
|
|
ctx->target.x, ctx->target.y, src->w, src->h,
|
|
|
|
EINA_TRUE, EINA_FALSE);
|
|
|
|
}
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->context_free(engine, drawctx);
|
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
|
|
|
evas_ector_buffer_engine_image_release(src->buffer, image);
|
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->image_free(engine, surface);
|
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
|
|
|
ctx->target.surface = NULL;
|
|
|
|
|
2014-03-02 01:39:08 -08:00
|
|
|
return EINA_TRUE;
|
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
|
|
|
|
|
|
|
fail:
|
2017-08-25 10:51:53 -07:00
|
|
|
ENFN->image_free(engine, surface);
|
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
|
|
|
ctx->target.surface = NULL;
|
|
|
|
|
|
|
|
ERR("Failed to render filter to target canvas!");
|
|
|
|
return EINA_FALSE;
|
2014-01-16 22:05:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-16 20:32:25 -08:00
|
|
|
/* Font drawing stuff */
|
|
|
|
Eina_Bool
|
2017-05-12 15:03:05 -07:00
|
|
|
evas_filter_font_draw(Evas_Filter_Context *ctx,
|
|
|
|
void *engine, void *output, void *draw_context, int bufid,
|
2014-01-16 20:32:25 -08:00
|
|
|
Evas_Font_Set *font, int x, int y,
|
|
|
|
Evas_Text_Props *text_props, Eina_Bool do_async)
|
|
|
|
{
|
|
|
|
Eina_Bool async_unref;
|
|
|
|
Evas_Filter_Buffer *fb;
|
2015-12-08 17:45:53 -08:00
|
|
|
void *surface = NULL;
|
2014-01-16 20:32:25 -08:00
|
|
|
|
|
|
|
fb = _filter_buffer_get(ctx, bufid);
|
2017-01-05 04:29:32 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(fb, EINA_FALSE);
|
|
|
|
|
2017-04-02 23:34:10 -07:00
|
|
|
surface = evas_filter_buffer_backing_get(ctx, bufid, EINA_TRUE);
|
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
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(surface, EINA_FALSE);
|
2014-01-16 20:32:25 -08:00
|
|
|
|
2016-01-04 01:00:30 -08:00
|
|
|
// Copied from evas_font_draw_async_check
|
2017-05-12 15:03:05 -07:00
|
|
|
async_unref = ENFN->font_draw(engine, output, draw_context, surface,
|
2016-01-04 01:00:30 -08:00
|
|
|
font, x, y, fb->w, fb->h, fb->w, fb->h,
|
|
|
|
text_props, do_async);
|
|
|
|
if (do_async && async_unref)
|
2014-01-16 20:32:25 -08:00
|
|
|
{
|
2016-01-04 01:00:30 -08:00
|
|
|
evas_common_font_glyphs_ref(text_props->glyphs);
|
|
|
|
evas_unref_queue_glyph_put(ctx->evas, text_props->glyphs);
|
2014-01-16 20:32:25 -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
|
|
|
evas_ector_buffer_engine_image_release(fb->buffer, surface);
|
2014-01-16 20:32:25 -08:00
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
/* Clip full input rect (0, 0, sw, sh) to target (dx, dy, dw, dh)
|
|
|
|
* and get source's clipped sx, sy as well as destination x, y, cols and rows */
|
|
|
|
void
|
|
|
|
_clip_to_target(int *sx /* OUT */, int *sy /* OUT */, int sw, int sh,
|
|
|
|
int ox, int oy, int dw, int dh,
|
|
|
|
int *dx /* OUT */, int *dy /* OUT */,
|
|
|
|
int *rows /* OUT */, int *cols /* OUT */)
|
|
|
|
{
|
|
|
|
if (ox > 0)
|
|
|
|
{
|
2014-03-03 00:45:15 -08:00
|
|
|
(*sx) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*dx) = ox;
|
2014-01-22 01:41:00 -08:00
|
|
|
(*cols) = sw;
|
|
|
|
if (((*dx) + (*cols)) > (dw))
|
2013-12-08 22:57:50 -08:00
|
|
|
(*cols) = dw - (*dx);
|
|
|
|
}
|
|
|
|
else if (ox < 0)
|
|
|
|
{
|
2014-03-03 00:45:15 -08:00
|
|
|
(*dx) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*sx) = (-ox);
|
|
|
|
(*cols) = sw - (*sx);
|
|
|
|
if ((*cols) > dw) (*cols) = dw;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-03-03 18:44:19 -08:00
|
|
|
(*sx) = 0;
|
2014-03-03 00:45:15 -08:00
|
|
|
(*dx) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*cols) = sw;
|
|
|
|
if ((*cols) > dw) (*cols) = dw;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (oy > 0)
|
|
|
|
{
|
2014-03-03 00:45:15 -08:00
|
|
|
(*sy) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*dy) = oy;
|
2014-01-22 01:41:00 -08:00
|
|
|
(*rows) = sh;
|
|
|
|
if (((*dy) + (*rows)) > (dh))
|
2013-12-08 22:57:50 -08:00
|
|
|
(*rows) = dh - (*dy);
|
|
|
|
}
|
|
|
|
else if (oy < 0)
|
|
|
|
{
|
2014-03-03 00:45:15 -08:00
|
|
|
(*dy) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*sy) = (-oy);
|
|
|
|
(*rows) = sh - (*sy);
|
|
|
|
if ((*rows) > dh) (*rows) = dh;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-03-03 18:44:19 -08:00
|
|
|
(*sy) = 0;
|
2014-03-03 00:45:15 -08:00
|
|
|
(*dy) = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
(*rows) = sh;
|
|
|
|
if ((*rows) > dh) (*rows) = dh;
|
|
|
|
}
|
2015-06-24 23:12:32 -07:00
|
|
|
if ((*cols) < 0) *cols = 0;
|
|
|
|
if ((*rows) < 0) *rows = 0;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2015-06-09 05:29:13 -07:00
|
|
|
#ifdef FILTERS_DEBUG
|
2013-12-08 22:57:50 -08:00
|
|
|
static const char *
|
|
|
|
_filter_name_get(int mode)
|
|
|
|
{
|
|
|
|
#define FNAME(a) case EVAS_FILTER_MODE_ ## a: return "EVAS_FILTER_MODE_" #a
|
|
|
|
switch (mode)
|
|
|
|
{
|
2017-01-23 00:55:17 -08:00
|
|
|
FNAME(SKIP);
|
2013-12-08 22:57:50 -08:00
|
|
|
FNAME(BLEND);
|
|
|
|
FNAME(BLUR);
|
|
|
|
FNAME(CURVE);
|
|
|
|
FNAME(DISPLACE);
|
|
|
|
FNAME(MASK);
|
|
|
|
FNAME(BUMP);
|
2013-12-12 17:03:47 -08:00
|
|
|
FNAME(FILL);
|
2013-12-08 22:57:50 -08:00
|
|
|
default: return "INVALID";
|
|
|
|
}
|
|
|
|
#undef FNAME
|
|
|
|
}
|
2015-06-09 05:29:13 -07:00
|
|
|
#endif
|
2013-12-08 22:57:50 -08:00
|
|
|
|
|
|
|
static Eina_Bool
|
|
|
|
_filter_command_run(Evas_Filter_Command *cmd)
|
|
|
|
{
|
2017-01-16 23:13:35 -08:00
|
|
|
Evas_Filter_Support support = EVAS_FILTER_SUPPORT_NONE;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2017-01-23 00:55:17 -08:00
|
|
|
if (cmd->mode == EVAS_FILTER_MODE_SKIP)
|
|
|
|
return EINA_TRUE;
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(cmd->output, EINA_FALSE);
|
|
|
|
EINA_SAFETY_ON_NULL_RETURN_VAL(cmd->input, EINA_FALSE);
|
|
|
|
|
2015-06-09 05:29:13 -07:00
|
|
|
#ifdef FILTERS_DEBUG
|
|
|
|
XDBG("Command %d (%s): %d [%d] --> %d",
|
2013-12-08 22:57:50 -08:00
|
|
|
cmd->id, _filter_name_get(cmd->mode),
|
|
|
|
cmd->input->id, cmd->mask ? cmd->mask->id : 0, cmd->output->id);
|
2015-06-09 05:29:13 -07:00
|
|
|
#endif
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2014-01-02 01:44:01 -08:00
|
|
|
if (!cmd->input->w && !cmd->input->h
|
|
|
|
&& (cmd->mode != EVAS_FILTER_MODE_FILL))
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2015-06-09 05:29:13 -07:00
|
|
|
XDBG("Skipping processing of empty input buffer (size 0x0)");
|
2013-12-08 22:57:50 -08:00
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((cmd->output->w <= 0) || (cmd->output->h <= 0))
|
|
|
|
{
|
|
|
|
ERR("Output size invalid: %dx%d", cmd->output->w, cmd->output->h);
|
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
support = cmd->ENFN->gfx_filter_supports(CMD_ENC, cmd);
|
2017-01-17 04:18:46 -08:00
|
|
|
if (support == EVAS_FILTER_SUPPORT_NONE)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-01-17 02:33:50 -08:00
|
|
|
ERR("No function to process this filter (mode %d)", cmd->mode);
|
2013-12-08 22:57:50 -08:00
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
|
|
|
|
2017-04-24 15:09:25 -07:00
|
|
|
return cmd->ENFN->gfx_filter_process(CMD_ENC, cmd);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static Eina_Bool
|
2017-08-25 10:51:53 -07:00
|
|
|
_filter_chain_run(void *engine, void *output, Evas_Filter_Context *ctx)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
|
|
|
Evas_Filter_Command *cmd;
|
2014-03-02 23:58:18 -08:00
|
|
|
Eina_Bool ok = EINA_FALSE;
|
2013-12-08 22:57:50 -08:00
|
|
|
|
2014-03-10 22:50:11 -07:00
|
|
|
DEBUG_TIME_BEGIN();
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
EINA_INLIST_FOREACH(ctx->commands, cmd)
|
|
|
|
{
|
|
|
|
ok = _filter_command_run(cmd);
|
|
|
|
if (!ok)
|
|
|
|
{
|
|
|
|
ERR("Filter processing failed!");
|
2014-02-06 18:22:36 -08:00
|
|
|
goto end;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
ok = _filter_target_render(engine, output, ctx);
|
2014-01-16 22:05:23 -08:00
|
|
|
|
2014-02-06 18:22:36 -08:00
|
|
|
end:
|
|
|
|
ctx->running = EINA_FALSE;
|
2014-03-10 22:50:11 -07:00
|
|
|
DEBUG_TIME_END();
|
2014-03-11 22:06:23 -07:00
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
ctx->post_run.cb(ctx, ctx->post_run.data, ok);
|
2014-02-06 18:22:36 -08:00
|
|
|
return ok;
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
typedef struct _Filter_Thread_Data Filter_Thread_Data;
|
|
|
|
struct _Filter_Thread_Data
|
|
|
|
{
|
|
|
|
void *engine;
|
|
|
|
void *output;
|
|
|
|
Evas_Filter_Context *ctx;
|
|
|
|
};
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
static void
|
|
|
|
_filter_thread_run_cb(void *data)
|
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
Filter_Thread_Data *ftd = data;
|
|
|
|
|
|
|
|
_filter_chain_run(ftd->engine, ftd->output, ftd->ctx);
|
2017-09-04 03:08:02 -07:00
|
|
|
_free(ftd);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
|
|
|
|
2017-03-14 22:49:50 -07:00
|
|
|
static void
|
|
|
|
_filter_obscured_region_calc(Evas_Filter_Context *ctx)
|
|
|
|
{
|
|
|
|
Eina_Rectangle rect = ctx->obscured.real;
|
|
|
|
|
|
|
|
// left
|
|
|
|
if (rect.x > 0)
|
|
|
|
{
|
|
|
|
rect.x += ctx->pad.calculated.l;
|
|
|
|
rect.w -= ctx->pad.calculated.l;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
rect.w -= (-rect.x);
|
|
|
|
rect.x = 0;
|
|
|
|
}
|
|
|
|
if (rect.w < 0) rect.w = 0;
|
|
|
|
|
|
|
|
// right
|
|
|
|
if ((rect.x + rect.w) <= ctx->w)
|
|
|
|
rect.w -= ctx->pad.calculated.r;
|
|
|
|
else
|
|
|
|
rect.w = ctx->w - rect.x;
|
|
|
|
|
|
|
|
// top
|
|
|
|
if (rect.y > 0)
|
|
|
|
{
|
|
|
|
rect.y += ctx->pad.calculated.t;
|
|
|
|
rect.h -= ctx->pad.calculated.t;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
rect.h -= (-rect.y);
|
|
|
|
rect.y = 0;
|
|
|
|
}
|
|
|
|
if (rect.h < 0) rect.h = 0;
|
|
|
|
|
|
|
|
// bottom
|
|
|
|
if ((rect.y + rect.h) <= ctx->h)
|
|
|
|
rect.h -= ctx->pad.calculated.b;
|
|
|
|
else
|
|
|
|
rect.h = ctx->h - rect.y;
|
|
|
|
|
|
|
|
if ((rect.w <= 0) || (rect.h <= 0))
|
|
|
|
memset(&rect, 0, sizeof(rect));
|
|
|
|
|
|
|
|
ctx->obscured.effective = rect;
|
|
|
|
}
|
|
|
|
|
2013-12-08 22:57:50 -08:00
|
|
|
Eina_Bool
|
2017-08-25 10:51:53 -07:00
|
|
|
evas_filter_context_run(void *engine, void *output, Evas_Filter_Context *ctx)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-09-04 03:08:02 -07:00
|
|
|
evas_filter_context_ref(ctx);
|
2017-03-14 22:49:50 -07:00
|
|
|
_filter_obscured_region_calc(ctx);
|
|
|
|
|
2017-04-12 20:08:31 -07:00
|
|
|
ctx->run_count++;
|
2017-03-22 00:55:26 -07:00
|
|
|
ctx->running = EINA_TRUE;
|
2014-01-22 23:54:50 -08:00
|
|
|
if (ctx->async)
|
2013-12-08 22:57:50 -08:00
|
|
|
{
|
2017-08-25 10:51:53 -07:00
|
|
|
Filter_Thread_Data *ftd;
|
|
|
|
|
2017-09-04 03:08:02 -07:00
|
|
|
ftd = calloc(1, sizeof(*ftd));
|
2017-08-25 10:51:53 -07:00
|
|
|
ftd->engine = engine;
|
|
|
|
ftd->output = output;
|
|
|
|
ftd->ctx = ctx;
|
|
|
|
|
|
|
|
evas_thread_queue_flush(_filter_thread_run_cb, ftd);
|
2013-12-08 22:57:50 -08:00
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
2017-08-25 10:51:53 -07:00
|
|
|
return _filter_chain_run(engine, output, ctx);
|
2013-12-08 22:57:50 -08:00
|
|
|
}
|
2015-06-03 03:59:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
/* Logging */
|
|
|
|
|
|
|
|
static int init_cnt = 0;
|
|
|
|
int _evas_filter_log_dom = 0;
|
|
|
|
|
|
|
|
void
|
2016-12-06 05:33:24 -08:00
|
|
|
evas_filter_init(void)
|
2015-06-03 03:59:11 -07:00
|
|
|
{
|
|
|
|
if ((init_cnt++) > 0) return;
|
|
|
|
_evas_filter_log_dom = eina_log_domain_register("evas_filter", EVAS_FILTER_LOG_COLOR);
|
2017-03-23 00:22:43 -07:00
|
|
|
evas_filter_mixin_init();
|
2015-06-03 03:59:11 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2016-12-06 05:33:24 -08:00
|
|
|
evas_filter_shutdown(void)
|
2015-06-03 03:59:11 -07:00
|
|
|
{
|
|
|
|
if ((--init_cnt) > 0) return;
|
2015-06-04 03:42:38 -07:00
|
|
|
evas_filter_parser_shutdown();
|
2017-03-23 00:22:43 -07:00
|
|
|
evas_filter_mixin_shutdown();
|
2015-06-03 03:59:11 -07:00
|
|
|
eina_log_domain_unregister(_evas_filter_log_dom);
|
|
|
|
_evas_filter_log_dom = 0;
|
|
|
|
}
|