i found evas_common_draw_context_apply_cutouts() was procsessing 300+
cutouts and as it's O(n^2)/2 to try and merge adjacent rects for
cutouts this really performs like complete junk. we apply cutout rects
a LOT. this is not the best solution, but it's quick and much faster
than doing the clipouts which drop framerate to like 1-2fps or so in the
nasty case i say (tyls -m of photos in a dir with a 2160 high
terminal).
this figures out the target area to limit the count of rects
significantly so O(n^2) is far far better when n is now < 10 most of
the time. and for the few operations where it's a high value this now
uses qsort to speed up merges etc. etc.
@optimize
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
Summary:
When the proxy's source is updated, the proxy's event list will be
updated, too. But there is no way now. So add defensive code for
protecting segment fault.
@fix
Reviewers: woohyun, raster, jpeg
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4508
this doenst change functionality but just cleans up the file
whitespacing and formatting and removed commented out junk, 80 column
wrapping/overflow etc.
As derek pointed out, 'stride' here is an integer so does not need a
float comparison, so just use a simple integer comparison.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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.
Only the size of events_whitelist isn't enough, because in some
cases the user may be disabling the usage of a specific seat.
Considering the following scenario, the issue will easy to understand:
- an application with two entries (one to be used by seat 1 and other
by seat 2)
- the first seat is announced - it is enabled for entry 1 and
disabled for entry 2
- the second seat is announced
Before second seat is announced, the first seat would be able
to input the entry 1, because the events_whitelist of such
object will continue empty.
So a flag will be used to identify an object with active
filter.
Reviewed By: iscaro
Differential Revision: https://phab.enlightenment.org/D4498
It doesn't make sense to remove it when a seat is added
to the list. It should be removed only when this seat
is blocked.
But when the list receives its first item, then
it also should be checked if the focused seat
is the one just added, otherwise the previous one
must be removed.
After a previous patch, mask_subrender worked differently, and
didn't reset the object's cache clip color. This made evas_suite
fail. But also it seems some other issues creeped in and it was
necessary to fix the test case by adding data_updates (mistake!)
and removing an invalid draw call.
This fixes a rare crash in the SW engine when a masked mask is
to be rerendered. The clip adds more safety as the lower render
draw functions assume it is properly set.
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.
Carsten Haitzler
Jiwon Kim
Hosang Kim
Daniel Kolesa
Jean-Philippe Andre
Chris Michael
Jee-Yong Um
Cedric BAIL
Derek Foreman
Bruno Dilly