Here's the situation:
1. A container (genlist) has a mask, M0.
2. An item I0 inside this container uses a proxy P0 as render object
rather than the item directly (eg. for zooming in/out).
3. An element E0 inside this item has another mask, M1.
Theory:
1. The proxy surface for P0 is rendered, and M1 is applied to
the element E0.
2. The proxy P0 is rendered on the canvas, with M0 applied.
Practice:
1. The element E0 is prepared for rendering, this triggers
a mask subrender for M1.
2. M1 is rendered with M0 as a prev mask, then kept in cache and
not redrawn (no geometry change, etc...)
3. When P0's surface is rendered, M1's surface is the result of M1+M0.
4. When P0 is drawn on screen, we can see the effect of M1+M0 as
P0's geometry might be different from the item's I0.
Solution:
Discard prev masks and force a mask redraw when we're inside a
proxy. Ideally we should detect if the prev mask belongs to the
insides of the proxy or not.
Problems:
_mask_apply_inside_proxy() is definitely not correct, but it's
not easy to test it. Anyway I believe that in order to properly
implement all of this, we need to rethink evas_render and
the draw context. Non-primary render surfaces (maps, proxies,
masks, filters, ...) should be rendered with a clean context
and clipping, masking, etc should be computed appropriately.
Always assume use_mapped_ctx as true, the caller of evas_render_mapped
must ensure that the context is suitable (so either clean or contains
the appropriate clip info).
Also pass do_async to mask_subrender. For now it will always be reset
to false as the SW engine requires sync render to convert from RGBA
to Alpha (not great). The upcoming GL async engine should be able to
render masks asynchronously without any problem.
This can avoid some invalid render from evas_render_mapped in
a rare case. I'm not sure about the conditions but I know for
sure that at the moment mask_subrender should be only rendering
plain old images into a dedicated surface. So no need for
evas_render_mapped here.
It was never used, except in dubious situations (most likely a typo).
A clean context is now used in the top-most call to
evas_render_updates_internal_loop.
This makes code shorter and easier to read (imo).
Also introduce ENCTX for the engine context. It's used in a couple
places and I believe it's just wrong - but works because the engine
context and the current context are the same.
This will allow partially rendering a proxy in a smaller image,
limited to the specified region. At the moment, this will allow
apps to create proxies of very large objects and let them deal
with the geometry & clipping.
This is not directly solving the issues with adding a filter
to textblock or the infinite page scrollers.
@feature
This makes efl_loop_get() work on evas objects, returning the
main loop as expected. Also make the loop a property of the
Loop_User class (shouldn't it be called Efl.Loop.User instead?)
I added a way to respect the object's alignment when adding them
to a stacked box, but that alignment should only be used when the
box align is set to fill, otherwise both aligns would conflict.
See 3df7b717c9
The hash implementation demonstrated that too much memory was being used
to store the Evas_Object_Pointer_Data. In order to reduce the memory usage
this patches now changes the Evas_Object_Pointer_Data storage to an Eina_Inlist and
now Massif profiles shows that the memory usage was drastically reduced.
In order to properly block events from a given seat, Efl.Canvas.Object must
override the efl_event_callback_[legacy]_call to check if the event
is allowed or not.
With this new API one can block or unblock keyboard, mouse and
focus events that was originated from a seat. This is useful to
create applications that wants to establish some kind of seat segregation.
Summary:
EINA_COW_WRITE_BEGIN and EINA_COW_WRITE_END's parameters must be same.
But 'Read' paramter is different. So wrong variable's value is changed.
@fix
Reviewers: woohyun, Hermet, cedric, raster, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D4472
evas_render_method_lookup calls evas_module_find_type that
in turn actually goes and loads the module. All we wanted to
know was whether the render_method corresponded to one of the
wayland engines.
See 453770137f
In C we need this to make clear that we really do not accept parameters.
Found by the smatch source code matcher. I had run and fixed this before
but it seems to creep in again over time.
Directly in the beginning of the function we check if key is
<= EFL_INPUT_VALUE_NONE and return if this is true. No chance key could be
EFL_INPUT_VALUE_NONE below here.
CID: 1361997
Continuing the loop if the returned pdata is non-NULL does not make sense.
What Coverity actually found was that if we have cobj_pdata NULL here we
would happily deref it the line afterwards and crash.
Guilherme, Bruno if something else was intended here feel free to change it
again.
CID: 1366822
There were some obj->map->surface validation check
but final map drawing was in the out of the surface valid scope.
Actually, this change does nothing but logically this change makes sense.
After @cedric's commit 6427c77707 we end up with E
not working in Xephyr, because evas_common_shutdown() is called
too many times (init_count == -1). So I'm being paranoid and
tracking whether Evas has initialized or not evas_common. That
way we end up with exactly the right number of inits. We even
reach 0 after E shuts down :)
It's a rare case but a possible scenario that textblock is not updated
properly in case of textblock rendering via proxy/map.
If the textblock state turned out with an invisible state,
its relayouting won't be up to date. But actually, it could be rendered
by map/proxy. In that case textblock text layouting would be incorrect.
Additionally, removed evas event freeze state there because map/proxy won't
be drawn under the event freeze state always.
@fix
This patch introduces possibility to enable key locks and modifers by seat.
It's very useful when the user has two keyboards attached to different seats.
This patch introduces the possibility to set the pointer mode and
query other properties like current position per pointer device.
The old API will still works, however it will only act on the default seat.
This reverts commit bba368cf79.
if this is causing test suite fails ( i saw no actual visual problems
tho in apps or e etc.)... then revert. sadness. :(
remove some extra looping and if checkign that is taken care of
already and just is pointless extra checks in the code creating
overhead. tiny amounts, but the amount of meaty speedups lef it
running low, so profiling, reading, working and repeating.
@optimize
evas_object_clip_recalc was already called ... multiple times in
pending and phase1 on all objects, so there is no value in calling it
again and again in later evbas render phases when it's already been
done.
this and moving this to a real func sees evas_object_clip_recalc usage
in perf drop from 1.8% to 1.4% or so of total perf sample time. tiny
win, but we're at the point where i can't find big meaty wins, so i'm
looking for a string of small wins to add up.
@optimize
evas_object_clip_recalc is big. it's fat. it shouldnt be inline. so
make it a real function. being inline just hurts performance by making
our code bigger, hurting l1 instruction prefetch and cache
performance. this function isn't small. it's huge and should not be
inline basically because of that reason.
also throw in some likely/unlikely hints etc.
@optimize
part of rendering is figuring if obj is inside current geometry.
before we had to actuall poke around inside the object. this moves the
geometry into the active object array so the data is fecthed fast and
already there for filtering as this is the most likely thing to filter
out an object.
unfortunately this seems to have some bugsd and i'm baffled why, so
leave it there and ifdefed out for now for suture hunting.
in much of phase1 we already know the evas object protected data ptr,
so dont scope data get it or even pass the eo obj id around as we can
get it from obj->object