If an evas object is a wayland dmabuf, uses native surface 5 or higher,
and has a scanout handler set, then it meets the basic requirements for
placing on a hardware plane.
Summary: Before the value of stride is calculated, the weight and height of the rotated image should be set.
Test Plan: {F1409510}
Reviewers: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4955
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Following a remark in the mailing list, it is pretty clear that
Efl.Gfx.View.view_size is not as simple as "image_size".
I have defined this new image_size as being the size of the
image file, and not what's currently loaded. So it will not
apply to proxies, gl views, 3d scenes, etc... but only to
standard image files loaded with file_set or mmap_set.
Supported objects:
- Efl.Canvas.Image (evas image)
- Efl.Ui.Image (elm image)
- Elm.Photocam (note: still needs some interface work)
@feature
I've done this by translating "Flip Page" to this new set of
EO APIs. In particular, absolute coordinates need to be used
in some calls, and the map needs to be calculated between
get and set operations.
This required an adjustment of the raw_coord API as the flip_page
code does some math after reading and then writing to the map.
Same for color. Those two properties now act like commands (ie.
like the other gfx map functions).
This also introduces a duplicate set of APIs to handle absolute
coordinates. Other solutions included:
- Use an enum to specify the type of coordinates (but then the
unit of cx,cy varies between non-unit relative position and
pixel position. Also this adds an extra argument to all those
function calls.
- Pass a special value (an empty eo object) as the argument for
pivot. Same remark about the unit as above. This way was
deemed too confusing because of the weird object.
Those two options have been discarded after asking the opinion
of a few developers I could reach.
@feature
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
When the filtered object is an image, without borders, map,
fill info or anything of this sort, then the filter input
buffer is really just a copy of the original image. We can
skip that to save on memory usage and pixel fetches.
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.
This make save() work on snapshot objects, provided the call
is done from inside render_post.
Also, this saves the filtered output of an image, rather than
its source pixels. Any call to save() on a filtered image must
be done from post-render as well.
Fixes T2102
@feature
This factorizes some of the common code for image render
and resolving is_inside (verifying alpha value of a pixel).
This should also be used by save(), as well as buffer_map().
This patch introduces lots of whitespace changes by using return
instead of long if() {} or else {} blocks.
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.
If anything in the canvas needs redraw and a snapshot object
happens to intersect with the update region then it was redrawn,
even if all objects below it hadn't changed. This has an insane
performance impact when you apply a blur filter on the snapshot
object. Walking the object list will always be cheaper than
rendering the snapshot!
Note: Added a FIXME comment and forced clean_them to be true
because some odd behaviour happens when breaking with GDB and
the array snapshot_objects keeps growing at each frame (I guess
only if we miss a frame or something like that).
if its a file downloading (to a tmp location) or a zip/tar/whatever
file being extracted also to a tmp location and that tmp file needs to
be removed after ...you need to keep the obj around to know when to
delete the file. this makes the keeping optional and you query if the
vpath obj is meant to be kept or not. if it's not it's safe to del
immediately.
this cuts down 1 obj per image obj/edje obj when generally unused.
save some mem.
several calls, specifically evas_object_change_reset,
evas_object_cur_prev, and evas_object_clip_changes_clean that are
called directly or indirectly as part of evas render on at least every
active object if not more, were doing full eo obj lookups when their
calling functions already all had the eo protected data looked up.
tha's silly and just adds overhead we don't need. my test dropped
_eo_obj_pointer_get overhead in perf profiles from 4.48% to 2.65%. see:
4.48% libeo.so.1.18.99 [.] _eo_obj_pointer_get
4.23% libevas.so.1.18.99 [.] evas_render_updates_internal
2.61% libevas.so.1.18.99 [.] evas_render_updates_internal_loop
1.68% libeo.so.1.18.99 [.] efl_data_scope_get
1.57% libc-2.24.so [.] _int_malloc
1.42% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.09% libevas.so.1.18.99 [.] evas_object_clip_recalc.part.37
1.08% libpthread-2.24.so [.] pthread_getspecific
1.05% libevas.so.1.18.99 [.] efl_canvas_object_class_get
1.01% libevas.so.1.18.99 [.] evas_object_cur_prev
0.99% libeo.so.1.18.99 [.] _efl_object_event_callback_legacy_call
0.87% libevas.so.1.18.99 [.] _evas_render_phase1_object_ctx_render_cache_append
0.82% libpthread-2.24.so [.] pthread_mutex_lock
0.81% libevas.so.1.18.99 [.] _evas_render_phase1_object_process
0.79% libc-2.24.so [.] _int_free
vs now the improved:
4.82% libevas.so.1.18.99 [.] evas_render_updates_internal
3.44% libevas.so.1.18.99 [.] evas_render_updates_internal_loop
2.65% libeo.so.1.18.99 [.] _eo_obj_pointer_get
2.22% libc-2.24.so [.] _int_malloc
1.46% libevas.so.1.18.99 [.] evas_object_smart_changed_get
1.04% libeo.so.1.18.99 [.] _efl_object_event_callback_legacy_call
1.03% libevas.so.1.18.99 [.] _evas_render_phase1_object_ctx_render_cache_append
0.97% libeina.so.1.18.99 [.] eina_chained_mempool_malloc
0.93% libevas.so.1.18.99 [.] evas_object_clip_recalc.part.37
0.92% libpthread-2.24.so [.] pthread_mutex_lock
0.91% libevas.so.1.18.99 [.] _evas_render_phase1_object_process
0.84% libc-2.24.so [.] _int_free
0.84% libevas.so.1.18.99 [.] evas_object_cur_prev
0.83% libeina.so.1.18.99 [.] eina_chained_mempool_free
0.80% libeo.so.1.18.99 [.] efl_data_scope_get
of course other things "increase their percentage" as oe overhead now
dropped, and things seem to move around a bit, but it does make sense
to do this with no downsides i can see as we already are accessing the
protected data ptr in the parent func.
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 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.
Summary:
If border left+right >= image width, center area does not rendered.
Although adjusement logic, _draw_image()'s src_w can be a 0.
This commit try to secure center area at least 1 pixel.
This should fix T5057
@fix
Reviewers: raster, jypark, jpeg
Subscribers: cedric
Maniphest Tasks: T5057
Differential Revision: https://phab.enlightenment.org/D4538
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
Summary:
Someone calls evas_object_image_file_set() and set orient,
and then re-set another file.
At that time, there is a mismatch between Evas_Image_Data's
cur->orient and engine's orient data.
So, "file_set(a) -> orient_set(90) -> file_set(b) -> orient_set(90)"
is not working now.
Therefore, when a file_set() is finished, initialization is needed.
@fix
Reviewers: jypark, jpeg
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4515
This fixes evas_object_image_save after changing the orientation
of an image in the GL engine. In SW engine the pixel data is rotated
in memory, so things worked fine from the beginning. In GL we may
have to go through loops and hoops in order to rotate and fetch the
data from the GL texture.
This should fix ce45d44.
This reverts commit 4e110a34bf.
Urgh. I'm stupid. Conceptually I still like the idea of the
region proxy, that only renders part of the source object
in a proxy surface. The problem right now is that the proxy
subrender mechanism renders to a surface that belongs to
the **source** and not the proxy object. As a consequence,
the region would become a property of the source, rather than
the proxy, which is not at all the intention of the original
patch. In other words, everything would fall apart if an object
has more than one proxy, for whatever reason.
I realized that when trying to actually test the region proxy.
It didn't work at all. Revert for now.
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
evas render in phase1 in order to generate update rects, active,
render etc. object arrays has to walk every object in our tree. this
is a waste of time if we already have walked objects in a previous
frame if they havent changed, so cache this data in render cache in
smart objects to avoid re-walking and now just dumbly "memcpy" these
cached arrays into the master array. i have seen cpu usage by e drop
like about 15% in the sencarios i'm looking at "enlightenment
compositor with some window updating animation all the time, but most
other stuff being static).
@optimize
this tests rendering of images with border scaling if they are small
(smaller than 256x256) to reduce geometry. part of testing a cpu
reduction effort in gl engine by pre-rendering primitive objects to
buffers.
The proper way to use the pixel_get callback and dirty flag
is to also specify which exact region has been updated
with data_update_add.
Unfortunately many apps and even GLView are relying on
invalid behaviour that forced full redraw of the image
even though data_update_add was never called.
This amends c1a080f5e4
There is no dirty flag equivalent in EO as there is no
pixel_get callback defined (yet). One problem is that the GL
API is not defined, and may prove hard to define for bindings...
this is how you would possibly use prepare stages for objects like
image objects by pre-rendering them to a buffer. this is not complete
and it's actually disabled right now, but it's to show how it might be
done. some more exploring is needed, but this is to share how it
might/should work.
preparing an object is a good idea. especially with gl. you want to do
texture uploads BEFORE using textures all in one batch. otherwise this
may mean the gl implementation has to make a copy of your data in a
tmp location then copy it in later when texture becomes "unused" as it
may be in use at the moment, or it may have to stall and wait.
i have seen somewhere around 7-10% speedups on nvidia and intel
drivers with this on given a very special test case i brewed up (1000
32x32 images where i change 1 pixel every frame). this should have
impact really when we are modifying textures a lot. this is all i've
implemented for now, but this should/would/could do much more like
re-order map, proxy renders to render FIRST in a pre-render list
instead of inline and to pre-render fbo/buffer content for complex
objects like text or textblock etc.
Summary:
the canvas image is the only one presenting the load api, in all other
implementations you would only see error messages.
Reviewers: jpeg
Subscribers: cedric, raster
Differential Revision: https://phab.enlightenment.org/D4380
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
If the pixels of image object has updates
via native_suface_set api with TBM surface,
does not update on screen(no rendering)
Reviewers: jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4340
if image object's first alpha value is false, evas_object_image_alpha_set function did not work.
opaque_valid is always 1 even though has_alpha value changed.
if clipped color changed and not object color on image objects, then
the updates could be missed. this also fixes some corner cases where
opaqueness should not count for update deletion too. this bug seems to
have been here a while unnoticed.
fixes T4246
@fix
so if an img obj had some update regions and was opaque, it didnt del
an update region first before adding the updates, thus possibly
letting update regions pass through the opaque image area
@fix
this fixes over-rendering (where we render the whole image) if it has
a border set. do proper region updates if the image has a border but
is not scaled and the fill is at 0 0 and sams size as the object etc.
etc. so this is simple and doable.
this fixes T4123
this just makes it more obvious where its handling the opaque middle
fill case. see T4123 - i was just reding the code and this seemingly
does the right thing.
i don't know for sure if this fixes T4103 but in theory i think it
might given a reading of the backtrace and a guess at what might
happen, so try this fix. it doesn't hurt and can only help.
@fix
Derek Foreman
Cedric Bail
Jaeyong Hwang
Jean-Philippe Andre
Daniel Kolesa
Carsten Haitzler
Jiwon Kim
Chris Michael
Hermet Park
Marcel Hollerbach
jiin.moon
Ji-Youn Park
Tom Hacohen