ssometimes the evas render updates are a list of Render_Updates
structs ... sometimes Eina_Rectangles. this is horrible and i think a
bug turns up (but its not reproducable on linux - just bsd) with an
invalid free ... likely because we free() a ptr from the mem pool
eina_rectangle gets rects from. thats most likely the cause of
https://phab.enlightenment.org/T3226 - but as i can't know for sure,
this is a guess, but readiong the code i see posible vectors of
problemss here ... maybe.
so this redoes the update rects to ALWAYS be Render_Updates struct
and appropriately returns correct structures etc. etc. in api which
demand a list of Eina_Rectangles there.
pending testing on foreign sysstems to confirm this by @netstar
@fix
Setting the no-render flag on an elm widget had no effect,
as it was not properly propagated to its children. This should
fix that, but I'm not a fan of the solution.
Fixes T3371
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.
Previously, _evas_render_can_use_overlay would segfault here when
trying to make use of an Evas_Video_Surface. This is because eo_tmp
variable was never reassigned to be the smart parent before we tried
to get eo data from it.
@fix
NB: Thanks Frenchie !! ;)
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
this is not ideal since it triggers a client-side rerender of every object
which was clipped to the master clip (double render) and then this ends up
forcing the server to rerender the same area twice as well
not only that, it causes all surface damages to to be the size of the entire
window - framespace for every frame
@fix
while not occurring immediately before flush as in sync rendering, this
is functionally close enough that it will serve the purpose for which the
callback was intended, namely receiving a callback that occurs after render
update calculations have occurred but before flush happens
@fix
ref cbb447c878
This reverts commit cbb447c878.
1. this is wrong because evas_render_pipe_wakeup() is being called IN
THE RENDER THREAD. it... SENDS a wakeup back to the mainloop with
evas_async_events_put(data, 0, NULL, evas_render_async_wakeup);
and you can see that evas_render_async_wakeup() calls
evas_render_wakeup() and in evas_render_wakeup() flush pre/post are
called, but since the trhead does the flush we cant realyl call
before/after, but it retains order... IF there are updates (haveup).
so calling these callbacks FROM a thread is now leading to apps
mysteriously exiting. this is mucho bad. just at random i now have my
terminals exiting.
This time it's only about performance. We seem to be setting the
changed flag too often, which might trigger unnecessary redraws.
- map flag is set if there is currently a map AND it's not an image
object (because images can map themselves)
- hmap flag is set if there was a map before
So, map != hmap does not imply a transition between a mapped and
non-mapped state. Add an extra check before marking the clip
as dirty and changed.
While cached surfaces is a topic we're discussing recently,
this code is dead right now, and we will have to redesign the
buffer caching better to handle proxies, maps, smart objects, etc...
When the no_render flag was set on a proxy source, the object would
not be visible, but it would also not render inside the proxy surface,
which completely beats the purpose of this flag. This patch makes
the objects render inside a proxy surface.
evas_object_clipees_has is far cheaper than evas_object_clipees_get in case of checking if
clipees exist or not. This should improve the performance in case of large set of clipees.
@fix
As spotted by @FurryMyad I inverted the logic for source_clip.
This should restore the proper behaviour while keeping my previous
fixes working. See D2940.
This is an ugly hack to fix an issue reported in D3114. I don't
understand how the proposed patch could even fix anything given
the current situation.
Test case:
- Create edje object with textblock inside
- Clip out edje object (--> all children become not visible)
- Take textblock from edje and set it as source of a proxy
- Mark proxy as source_clip
Result: Nothing visible.
Expected: Proxy should contain the textblock object, since
source_clip means we ignore the edje object's clipper, and
only care about the textblock's clipper (entire canvas).
Here's what was happening:
- During a first pass, textblock is not visible, cur->cache.clip
is calculated, marked as clip_use=1 with geom 0,0 0x0
- In a second pass, the proxy is rendered, which needs to draw
the textblock in a surface. But cache.clip was used and it was
wrong.
Solution:
- Ignore cache.clip when rendering inside a proxy. I'm pretty
sure there are other instances where cache.clip will still
be a problem.
Problem: textblock never called relayout since it was not
visible.
Conclusion: cache.clip needs to die. It's a legacy optimization
that now causes more issues than it fixes.
Test case: elementary_test -to "Evas Map 3D"
The cube was clipped to its top-left corner.
What's really weird is that this code patch is for non-mapped
objects.
@feature
this should unload mainloop some more and have pixel upload now in a
thread - same as rendering. this eeems to work where i see it so let's
put this in and see with further testing.
Inside a proxy, clipping information might be wrong since the
source object may be at a different position than within
the proxy. If source_clip is not set, then we need to discard
all clips that are outside the proxy context.
So we just propagate the clip information inside the current
draw context, and even recurse from clipper to clipper to
find the final state of clipping.
Map and proxies and others (who said masks?) should definitely
rely more on the same model.
This code is not a mess. At all. You gotta love evas_render.
Use context_dup to inherit from previous contexts in a clean
manner. This removes the need for restoring the previous
clip information.
Plus, this commit removes lines of code so it must be good, right?
After clip_image_get, the old mask may be replaced by a new one,
and unref'ed, but it is later on set back as the context mask image.
Maybe it's possible that there was 0 reference and the image
got freed in between.
No idea how to test this.
@fix
NOTE: it would be nicer to setup a specific context for each snapshot
and walk all the child below. If any of them did change, only trigger the
full redraw in that case (and of course only if a filter with blurr does
use it somewhere).
This should theorically work, need some test. Design is easy to understand. Render
every part of a snapshot object by rendering the content below it, before rendering
the stack above it using that object content.
i think this has been disabled for a while. image unloading is broken
- esp with gl enigne as due to async move it was effectively disabled.
this re-enables it. unloading is deferred with a managed list of things
needing unloading and then when any async sw renders are not busy any
more - do the unload then in the mainloop of all pending/flagged
images to unload
@fix
Those two functions were doing exactly the same thing[1], which
is free an image, so this commit only attempts to simplify the code
a little bit.
[1] Actually image_map_surface_free() might even not have worked
properly with cserve2 sw (calling unload instead of close).
Those objects should never be rendered on the canvas, even if they
are visible. On the other hand, they need to be rendered in mask or
proxy surfaces.
note: this patch includes some extra whitespaces changes :(
@feature
On minimizing, free all mask surfaces. This could save a lot
of memory.
Also, write "proxy" COW only when there is a surface (the "proxy"
pointer itself is always valid and non-NULL).
Right now the engines don't support mask tiles so we can't
just scale up an image on-the-fly when doing a masking operation.
Skip fast path and force render of border images into their own surface.
Situation:
- Evas Object A has a clip C and a map M.
Problem:
- Clip C will be applied once inside the map surface S and
again when the surface S is drawn to the canvas.
Solution:
- Track whether the current object is the mapped object
or a child of the mapped object. In the first case,
discard the clipper when rendering to the map surface.
In the second case, the child's clipper is PROBABLY[*]
inside the map, so it should be applied when rendering the
map surface itself.
Note: This also applies to masks.
[*] This is clearly not the ultimate clipping fix.
In some rare cases, a mask would be rendered (from mask_subrender)
into a surface that is NOT an FBO. This would happen because the
previous surface was a "scaled GL image" and its size would
match the required geometry.
That took a while to figure out...
http://thecodinglove.com/post/111546429281/when-i-finally-solve-a-nasty-bug
The function image_scaled_update() frees() the old scaled image
passed as input if it doesn't match the old dimensions. This commit
will avoid double frees.
Edje may not set the filled flag on an image even if its fill
properties make it fill the whole object. For masking, it can
then be considered as a filled image.
If the image is not "filled", then we can't assume its image
source geometry is the same as its texture geometry.
Note: Implementing a fast path for non-filled images would
require a hell of a lot more work (need to cut the render
into a lot more triangles) for little real-life use.
Call object's function to get the private engine_data (here, the
image object). Thanks Dongyeon for your patch which inspired me to
do that instead of forcing pre_render.
This will currently optimize most of the masks when using the
GL engine[1].
This is a very special case that adds a highly optimized path
for masking in GL. It works by creating a virtual image, containing
a pointer to the original image and a new geometry[2].
Instead of creating a new FBO-based surface (image_map_surface),
we refer to the original image and adjust the mask geometry on
the fly.
KNOWN BUGS:
- masking a map with such a scaled image is now broken.
[1] Right now all masks are simple Evas Object Image, so that means
all cases of masking, except masks of masks, or masks of maps,
will be optimized with this new method.
[2] This virtual image mechanism is still quite hackish and may
be improved (for memory usage, refcounting, etc...)
this adds a lock for when walking all the objects to generate render
commands for an async render. this allows even the object tree walk
plus update area caluclation to be moved off into async if every oject
that can change canvas state actually does so correctly. this change
adds all those lock block calls to synchronise with an async object
tree walk.
Fixes rendering in the following case:
- Object with a map has a mask
- Object is child of smart object which also has a map (eg. transit)
--> Masking did not apply to the children before this patch.
NOTE: This works fine in SW but still didn't work in GL, see the
following commit...
I know. This title does not explain anything. Whatever.
This fixes the following issue:
- Mask a genlist (big mask)
- Each item has an icon masked (small mask)
- Apply a map to the genlist
- Scrolling the genlist
--> The big mask still works but totally screws up the
small icons with masks.
Note: Once again this patch only affects code paths where an
object is a mask.
Yeah, mixing maps and masks of masks in a genlist leads
to tons of amazing bugs :)
This commit removes x,y from the "mask" field in an object,
as they are duplicates of cur->geometry.{x,y} but were not
properly kept in sync.
This patch fixes a situation of:
- A genlist in a map
- Each item has an icon masked
- Scrolling the genlist
--> The masked items would not render properly before this
patch.
Remaining known problem:
- Mask a genlist (big mask)
- Each item has an icon masked (small mask)
- Apply a map to the genlist
- Scrolling the genlist
--> The big mask still works but totally screws up the
small icons with masks.
Note: These changes look scary just before the release
but I would have to backport them to 1.13.x as they
definitely are bug fixes. Also, they only concern
code paths used exclusively by masking.
All those masking bug fixes become harder to explain. But here goes:
- Take a genlist, apply a mask to it (for example put everything
in an elm_layout). Also play with various objects in the genlist.
- Also apply a map to it (for instance, elm_transit zoom).
--> Now some elements will be masked, some others will not,
and some may even not render at all.
This patch restores a mask in the current drawing context, instead
of just unsetting it.
In a situation where an object with mask of mask is in a map
(Yes! It can happen!) the masks would not get properly "multiplied".
Now the problem is that some objects still seem to bypass some
masks... Hmm...
This is a left-over from a previous fix a few weeks ago.
The point of this "if" is just to avoid writing the COW value
if not needed.
For reference:
commit f876cf31f8
Author: Jean-Philippe Andre <jp.andre@samsung.com>
Date: Tue Dec 23 18:57:45 2014 +0900
Evas masking: Fix invalid geometry after mask redraw
Summary:
This is an attempt at fixing:
- T1767: The ultimate evil map & clip bug
Force recalculation and re-propagation of clipper geometry
after or just before a map is applied (only when transiting
between map enabled and map disabled).
I realized that doing clip_unset+clip_set in the E widget
code would fix the issue, but this is not a solution that
makes a lot of sense.
Unfortunately I have no idea about the side effects of this
patch, especially in terms of performance.
Fixes T1767 and maybe T1630.
Test Plan:
Open PackageKit popup in E, check the animations
and that clipping works fine both during, before and after
the animations.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: cedric, Hermet
Maniphest Tasks: T1767
Differential Revision: https://phab.enlightenment.org/D1897
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
While invesigating some clip & map issues, I found some very
strange piece of code:
{
tmp = a;
a = c;
a = tmp;
}
This actually comes from a very old code refactoring where a
line in-between was removed:
tobj = obj->cur.map_parent;
obj->cur.map_parent = obj->cur.clipper->cur.map_parent;
- evas_object_clip_recalc(obj);
obj->cur.map_parent = tobj;
Adding this line back there doesn't seem to do anything anyways.
So, let's just remove useless code.
For the record (legacy evas):
commit e1f6f3c5f239dfd95a307949acd5f98831c0c3c0
Date: Fri Aug 17 06:16:04 2012 +0000
evas/render - code refactoring.
SVN revision: 75351
Some complex examples of masking with mapped smart objects
would fail miserably, rendering the object without any mask,
and/or showing the mask itself somewhere in white color...
The memory usage graph was going up and to the right!
I was told this is always a good thing!
... maybe not this time :)
Hopefully I didn't forget a case. An intense session of
genlist scrolling with masks all over the place and masks
of masks didn't show any glitch, crash or memory leak.
This implements supports for masking inside evas_render, which
means:
- Render the mask itself into a surface (ALPHA if possible)
- Pass this mask surface to the draw context
- Apply mask recursively in case a masked object is contained
by another masked object.
@feature
Here's a macro that's used for debugging in some of the ugliest
ways possible: avoid passing an extra argument to a function when the
cost of always passing it is negligible (it's an int).
Fixes T1749.
If the children are rendered in the proxy render time,
they should not be reset the changes always since we don't sure
they will be rendered in normal rendering after.
In this case, we leave them as they are.
But maybe they can be optimized by comments says.
@fix
This patch fixes the proxy drawing problem that source won't be updated in some case
If the image object is the one member of the smart that has the proxy,
the proxy(image part) won't be redrawed properly unless evas tries to draw the image object.
This can be heppend if the image object is inactive cause of some reasone(ie. outside of the screen)
So, the proxy object never can be never updated even the image part is changed.
Now let try to be active if the parent is both active and source object.
and revert previous change with regarded to a739716cee,
that's no more required now.
@fix
Carsten Haitzler
Jean-Philippe Andre
Tom Hacohen
Chris Michael
Mike Blumenkrantz
Vincent Torri
Amitesh Singh
Cedric BAIL
Subhransu Mohanty
Jean-Philippe Andre
ChunEon Park
Cedric Bail
Taekyun Kim
Daniel Zaoui