This might not be used as over two consecutive runs all the
same buffers should be used. But it could happen if some
parameters in the filter change (eg. blur radius).
Fixes major (GPU) memory leaks. Reuse mode is still leaking.
If the obscured area in a snapshot object changes a lot, do
not try to keep track of it forever. Instead, redraw the filter
over the entire object region, without obscure.
This fixes a performance issue when an opaque window is moved
above a fixed transparent window (the latter has a snapshot with
blur filter).
This improves over the previous code for handling
snapshot objects and cutouts. Basically any opaque object
above a snapshot should be obscuring it. That is true
unless a crazy filter is applied, or the snapshot object
is itself the source of a map or proxy.
This also uses eina_tiler instead of a custom (and really
bad) algorithm to compute the obscure regions.
The situation is clearly visible in the Snapshot test case:
increase the radius and a red glow would appear. This is because
the snapshot object was not marked as needing redraw and so had
no pixels under the opaque rectangle.
This will reuse existing buffers by resetting only the minimum
required in the filter context (also reused). Work in progress,
as the actual reuse is disabled for now.
This avoids creating one more FBO and doing one more draw,
by rendering the image input data directly into the input
buffer. This also makes the code common between SW and GL.
When using a snapshot object we have access to exactly all
the pixels below it inside the snapshot surface. So, in order
to produce a nice blur, it is necessary to expand this snapshot
and then clip it otherwise the edges will look a bit ugly.
Unfortunately, there are still places where blurs didn't look
so good, as objects below an opaque region would never get
rendered into the snapshot object. So the edges, inside a
snapshot object, around an opaque region would have blur
artifacts.
This fixes that by shrinking the cutout regions by the radius
of the filter. Eg for blur this is the blur radius.
The test case in elm_test can exhibit this fix very clearly:
a red glow would be visible around the opaque rectangle, but with
these changes we instead see the blurry edges of the objects
below the rectangle.
This will be most useful in a special case, where a filter is
used in a window decoration, applied to a snapshot object.
Another optimization that might be wanted is passing a list
of update regions (from the proxy or snapshot).
The filters don't support the obscuring region yet, only some
of the high-level logic is implemented.
Textblock filters support RGBA input which means legacy styles
can be used in conjunction with filtering. Not recommended, but
it works. Note: We may decide to drop this behaviour and use
alpha-only inputs for simplicity.
Still missing: support for filtering strikethrough, underline, or
embedded items
This is a function that allows passing variables from C or EDC
to the filter's Lua code. Useful in particular for color classes
from EDC.
This data would be the global data but we could eventually add
a markup tag to specify a data value per filter instance. For now
a single data value per tb object should be more than enough though.
If a gfx filter was applied to a block of text spanning over
multiple text items, then it would improperly render as the
filter context was stored in the format, rather than the text
item. This is fixed by using a list of contexts in the format
node rather than a single context.
This should save a bit of memory for all image & text
objects. This exploits the previous patch for the post-render
job queue added to evas, and simplifies this bit of code.
This is a preparation step for (experimental) textblock support.
Textblock objects won't have a single filter, and the buffer's
geometry wouldn't be that of of the object itself. Thus a few
internal APIs need to be reworked first.
Coverity reports this as a dereference before null check which implies
that 'pd' May be null here, so let's not use it before we check it.
Fixes CID1364114
Signed-off-by: Chris Michael <cp.michael@samsung.com>
EO is now extremely restrictive wrt. threads so that efl_data_scope_get()
can't work outside the main loop. This patch fixes the usage to create
sw buffers as shared objects (accessible from both the main loop and evas
async thread) and use plain old pointers where possible.
The buffers now have no parent because efl_add(CLASS, obj_from_mainloop)
does not work with shared objects. This is bad, as the buffers conceptually
belong to the main loop, and only need to be accessible from the draw thread
for a few calls. The main loop determines their lifecycle.
Fixes T4628
Those are marked as EINA_DEPRECATED since they are for legacy only,
and EDC is the preferred method.
Note: these are new in EFL 1.18.
I would rather have not added them as legacy APIs. This patch is
here to align to Tizen which added them by mistake. Also, remove
the "name" argument from filter_program_set as it's not required,
and also not there in Tizen's code base.
Sorry for the mess.
I just ran my script (email to follow) to migrate all of the EFL
automatically. This commit is *only* the automatic conversion, so it can
be easily reverted and re-run.
- Remove @beta flags,
- Update @since to match stabilization,
- Change methods to properties with keys,
- Use eo_prefix and add filter_ prefix to all properties since
they use very generic names,
The filter API stays under Efl.Gfx since there are other kinds of
filters, and this one is the particular "graphical filter" or
"effect" API.
The EO API mostly not change from an application point of view,
except for "source_get" which now returns a string directly. Also,
state and data can now be queried.
SW async render mode was broken because it was party sync, partly
async (bad hack in a recent commit). This patch fixes that by
using a proper callback for render_post (main loop).
Since the engines and ector now abstract all pixel access functions,
the only difference between GL and SW is the async rendering.
This implements a generic way of scaling buffers, using fake
RGBA_Image wrapping ector buffer maps. The underlying algo is
still the good old linear sw scaler.
Now the filters *should* be back to their previous level of
usability. Performance will probably be even worse than it was
before, for GL, as more glReadPixels may be involved. Optimization
now consists in actually implementing the filters with GL shaders.
This is a major refactoring of the evas filters submodule.
Use Ector.Buffer and the map/unmap methods instead of directly
accessing image buffers with RGBA_Image. RGBA_Image is still
used under the hood, for two reasons:
- Required for the final output (blend onto Evas itself)
- Required for the scaling routines
FIXME:
- Breaks proxy support (ie. all kind of texturing).
- This breaks filters support for the GL engine.
In a rare situation the filter would access an invalid buffer.
Solution: Stop messing with buffer references by properly
referencing and releasing them when not needed, rather
than stealing references and hoping for the best. (There were
flags tracking stolen references, but that was still madness)
Jean-Philippe Andre
Cedric BAIL
Chris Michael
Stephen Houston
Tom Hacohen
Amitesh Singh