Honestly I can't see why gfx & gfx.path "changed" need a manual
definition, instead of relying on EO. If the API needs to be
internal only, then EO needs to handle internal APIs. In this
case, the event was exposed as a C API but not a EO... why?
Summary:
The values(259200, 86400) are hard to know the meaning.
And we don't have to call gmtime() in for loop.
Test Plan: elementary_test -> calendar
Reviewers: jpeg, Hermet, shilpasingh, cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4717
ecore_wl2 contains a bunch of code for compositor side seat handling.
There's really no need for a client to do this, and E does the
compositor side seat stuff internally, so this code will never
be used.
This removes the unused code.
Summary:
When the keyboard mode state is changed, the keyboard_mode_event_cb will be called, too.
But there is no way to get keyboard mode manually.
Test Plan: Tested in Tizen device
Reviewers: jihoon, woohyun, id213sin
Reviewed By: jihoon
Subscribers: jpeg, z-wony, jsuya, cedric
Differential Revision: https://phab.enlightenment.org/D4786
so our yuv import funcs for gstreamer 1.x engine were ignoring the
plane offsets and strides provided by gstreamer. though this nicely
shows that these numbers provided are actually wrong - at least in the
testing with vaapi back-ends with gst.
so this fixes emotions' badness but there is still badness in gst
apparently. the numbers provided if used are just simply wrong for teh
image data. commented code in the src to show how to "Fix it up" by
forcing some alignment of content to get it to work.
@fix
This might not be used as over two consecutive runs all the
same buffers should be used. But it could happen if some
parameters in the filter change (eg. blur radius).
Fixes major (GPU) memory leaks. Reuse mode is still leaking.
An odd-sized image scaled down by 2 was losing 1 pixel during the
downscale, and it was not restored after scaling up. The same
happened with downscaling by 4 except the effect was even more
visible.
This meant that a moving snapshot with a large blur would trigger
some really ugly sampling issues if the content below was precise
(such a text).
If the obscured area in a snapshot object changes a lot, do
not try to keep track of it forever. Instead, redraw the filter
over the entire object region, without obscure.
This fixes a performance issue when an opaque window is moved
above a fixed transparent window (the latter has a snapshot with
blur filter).
This dramatically improves the performance and now seems
to give acceptable results. Eventually we need a quality flag
in order to enable this or not. Alternatively, "gaussian" blur
mode would skip this optimization, while "default" would trigger
it.
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 can help with performance when a large region of the
filtered image (eg. snapshot) is fully hidden by an opaque
object. For instance the window border is hidden by the
opaque window content.
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
If we delete the image that was the target surface for gl
rendering, a crash would occur on the next render cycle.
Unlikely but not impossible to trigger from app side.
@fix
This was a poor attempt at improving the performance but
obviously the root cause isn't fixed (too many texel fetches).
Uniform should (theoretically) work better than an attribute
the for loop. Just a guess here.
This also makes GL blur use a float value as radius, allowing
future extension to non-integer blur radii, as well as using
linear scaling as a fast blur approximation.
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.
The situation is clearly visible in the Snapshot test case:
increase the radius and a red glow would appear. This is because
the snapshot object was not marked as needing redraw and so had
no pixels under the opaque rectangle.
This will reuse existing buffers by resetting only the minimum
required in the filter context (also reused). Work in progress,
as the actual reuse is disabled for now.
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.
This optimizes the GL blur algorithm by reducing the number of
texel fetches (roughly half the number of before this patch). This
works by exploiting GL's interpolation capabilities.
This skips extra tests with image objects that have the
is_opaque() function. That way, if an object is marked as COPY,
rendering of all objects below it will be skipped.
This can dramatically help with performance when flagging a
snapshot object as COPY. This should not be done if a filter is
applied and is meant to blend with the underlying UI.
When using a snapshot object we have access to exactly all
the pixels below it inside the snapshot surface. So, in order
to produce a nice blur, it is necessary to expand this snapshot
and then clip it otherwise the edges will look a bit ugly.
Unfortunately, there are still places where blurs didn't look
so good, as objects below an opaque region would never get
rendered into the snapshot object. So the edges, inside a
snapshot object, around an opaque region would have blur
artifacts.
This fixes that by shrinking the cutout regions by the radius
of the filter. Eg for blur this is the blur radius.
The test case in elm_test can exhibit this fix very clearly:
a red glow would be visible around the opaque rectangle, but with
these changes we instead see the blurry edges of the objects
below the rectangle.
This will be most useful in a special case, where a filter is
used in a window decoration, applied to a snapshot object.
Another optimization that might be wanted is passing a list
of update regions (from the proxy or snapshot).
The filters don't support the obscuring region yet, only some
of the high-level logic is implemented.
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).
By simply splitting X and Y blurs in two passes we can improve
the performance of the blur filter a lot.
There is still much to be done to make it really fast and nice
looking:
- implement true gaussian blur (not sine-based approximation,
right now the actual blurs look different in SW and GL)
- exploit linear interpolation for R tap instead of R*2+1 taps
(a tap being a texel fetch)
- downscale & upscale large images with large blur radii