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
An invalid optimization was implemented in proxy rendering.
We can't assume a proxy is a smart object.
Refer to 5cefa00d0a.
Fixes T832.
Proxy rendering is still broken when using cserve2... :(
since the map_changed is reset right after the map is updated,
it could not decide to redraw the map surface properly.
now map_update() returns the value to redraw the map surface properly.
There was detected that pending_objects array of Evas structure of
email application stores at least 550 objects that never are removed
from this array. These objects are not active and are not about to render.
We know that once the decision not to remove changed objects from this
array was accepted. But then the criterion of leaving object in this
array was weakened.
We propose to weaken this criterion more sufficiently – do not store
in this array objects that can not be cause of whole canvas
invalidation. Our exact proposal for this criterion you can see in the
patch attached to this issue.
NOTE: This patch is a try, there may be some side effect especially with
mapped object that we didn't find, so it could be reverted if before the
release of 1.9 we see anything wrong.
Reviewers: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D354
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
if the some of children are the mapped object in source object tree as well as the the mappped object is invisible,
then they wont be render_pre() called.
this make sure those render_pre() in proxy rendering.
This bug is particularly visible in EFM video preview ( T 539 ). The problem is
that the logic for changed has evolved over time. At the beginning Evas canvas
was flat and could be handle in an array. It was then not using the changed flag
that much. This day, we are living with a tree and we need to propagate the
changed flag to the parent, so that when we walk them we only need to walk the
active objects and don't spend our time on branch that are completely static.
Sadly things did collide here. We remove all object that have been rendered
from the pending_objects array. That does include any smart object that was
processed even if one of the child was not. Once any of the child of that not
processed object is marked changed, it will be propagated up to the first
parent that is changed. As the parent of that one are marked as not changed
when evas_render walk the tree, he is blocked really early in the process and
never get a chance to detect that the child of a not changed object did change
and tada !
The fix is to add all the parent of all the object that are in the pending_objects
array back into the pending_objects list. So they will always be marked as changed.
Another alternative to this logic would have been to change pending_change to
filter out those and keep them around. I choose the first solution as I think it
will be more robust to catch all the parent in all case.
but this is not finished. this needs proper fixing. this is a quick
patch for just the worst. the real solution is discussed here:
https://phab.enlightenment.org/T457
cserve2 can't handle virtual files (mmap-only), by design.
Proper support can be added later on, but for now we might want
to just fallback to the normal cache functions.
Fixes photocam test
Wayland subsurfaces can be used as video surfaces too, similarly to
Ecore_X windows. However, they support a different set of features. Some
of them, like subsurface clipping and scaling, might be added in the
future, but so far we must work with what we have.
This commit allows to set an enum bitfield to the Video_Surface, with
the default value being one that will keep the same behavior as before,
for Ecore_X window. Thus, backward compatibility should not be broken.
It's possible to inform Evas that the surface in question is not able to
resize or scale, or that it's above or below the original canvas
surface. This allows Evas to show the surface itself, or use a buffer of
pixels instead, when the capabilities are not available.
If we are running on async render, some operations must be delayed, so
they will happen at the same time that the canvas rendering result gets
updated on the window/surface.
objects that were visible and marked as "render del" rects during render are now detected when they magically change visibility during the same render loop, fixing a very hard to reproduce E19 corner case related to fullscreen client rendering with nocomp disabled
<raster> for now all i can say is "put the patch in and lets see if things break"
NB: Master clip is needed so that things don't draw outside the client
area.
NB: This is a partial fix. Still a work in progress. Some remaining
issues with some various elm_tests that use evas_map.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Tracking only the async rendering canvases and just waiting for the last one
to finish rendering. This should be enough to sync all canvases since the
render thread orderly executes the commands.
evas_render_sync() will loop through all canvases and wait for their
rendering to finish. Since this function will execute from the main
thread that will sync all of them.
This check is not necessary but causes incorrect clipping issues.
At this moment, if primitive objects (except image) is the source then that code may be helpful but it doesn't guarantee same behavior for all the primitive objects.
So, right now removed it.
This is not the perfect solution at this moment. This doesn't consider the cached clipper's visibility at all.
But at least this would be better than exist works. Should be improved.
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
This causes the textblock layouting problem.
It should be checked when does it really render_pre() called.
If someone knows the reason of this, please ping me.
Before this patch, the proxy will be clipped if the source is clipped by output area even if the soure_clip is disabled,
Additionally, src_clip/src_event/src_visible options must be supported in edje.
Instead of moving the objects by adding the framespace offset to them,
use this offset when rendering them. This way there's no change in the
object's geometry/position, it works correctly with map, and will be
automatically updated in case that the framespace values change (for
instance if one sets a window to borderless).
There are 2 main places where changes were needed:
- output redraws, when they come from an object being changed, must be
add the framespace offset to their damaged area;
- checks to see if the object is inside a given rendering area, must
also add this offset, since the object is actually being rendered on
a different position;
This clipper caused several bugs already, and there are some bugs still
not fixed. Let's remove it and try to fix any remaining with some other
kind of solution that does not depend on adding or clipping objects
during the evas render phase, which causes unexpected behavior.
These objects should be clipped only during rendering, since keeping
them clipped after that allows for unexpected behavior on the
application side. For instance, an application could check if objects
have clippers before doing something to them, assuming that some objects
should have no clipper, but under wayland, after the first render
iteration, there will be no objects without a clipper.
This commit fixes this behavior by unclipping objects that had no
clipper prior to the render iteration.
Additionally, it fixes a bug where a maximized/fullscreen window could
have not all of its content rendered immediately. This was occuring
because some objects could be clipped to the framespace clipper, but
considered invisible in the beginning of the render phase, where they
are evaluated. They were considered invisible because the framespace
clipper object was not resized at that phase yet, and thus these objects
were being clipped out from the viewport.
There's an obvious typo in the function name, so appease my OCD and
rename it.
Patch by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
SVN revision: 83604
NOTE: Overall speedup of 7%. No benchmark on memory consumption yet
as they are still running ask me directly to get the number later
today.
SVN revision: 83052
Expedite biggest test memory win 100KB, average 10KB.
No slow down in proxy test (+/-3%). Speed up in most other
case (average speed up is +5%), likely due to much more
cache hit.
Elementary test show a win between 100KB to 600KB depending
on the test you are considering.
Now, you can see how I intend to use Eina_Cow and the expected
win we can have from it. I don't intend to do more for the
rest of the week so you have time to comment.
SVN revision: 82924
This new engine function will only be used in software generic for
now - since it's the only engine used with the async render.
This function has been introduced in order to avoid growing thread
command queue too much to draw a text_props at a time on render calls
from textgrid objects.
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 82832
NOTE: There is still an issue with text rendering, that
is still 4 times slower and impact all text object (text,
textblock and textgrid).
SVN revision: 81912
Also postpone marking the rendering flag until we know we will have
the draw thread do its work. This way we avoid waiting forever at
evas_render_rendering_wait() when the draw thread is also blocked.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 81798
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Carsten Haitzler
Jean-Philippe Andre
Cedric BAIL
Subhransu Mohanty
Jean-Philippe Andre
ChunEon Park
Tom Hacohen
Cedric Bail
Taekyun Kim
Daniel Zaoui
Daniel Juyung Seo
Viacheslav Lvov
Cedric Bail
Ulisses Furquim
Rafael Antognolli
Mike Blumenkrantz
Chris Michael
Sebastian Dransfeld
ChunEon Park
Raphael Kubo da Costa
Ulisses Furquim
Leandro Pereira
Paulo Alcantara
Gustavo Sverzut Barbieri
Mike McCormack
Vincent Torri