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).
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.
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 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 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.
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
Wait a second though, this implementation is not only incomplete
(no support for box vs. gaussian blur), it's also insanely bad in
terms of performance. Small radii may work fine, but at least blurs
render properly in GL with this patch (no more glReadPixels!).
The shader needs a lot of love, including in particular:
- support for 1D box blur single pass
- support for 1D gaussian (or sine) blur
- use linear interpolation and N-tap filters
- separation of 2D blur in two passes (high-level logic)
- potentially separation of large 1D blurs in 2 or more passes
knowing that 2sigma == sigma + sigma when it comes to the gaussian
bell curve.
This one was a bit more... "fun". I had to add a new vertex
attribute and obviously using a VertexAttribPointer led to
incomprehensible crashes. But a simple glVertexAttrib2fv makes
it work like a charm!
A rare option is not handled yet.
This reuses the existing mask infrastructure, but adds a color
flag to use the whole RGBA range, rather than just the Alpha
channel.
Filters are still very slow (glReadPixels and non-optimized use of
GL buffers...), but this is progress :)
This corrects two things:
- the blur filter high-level logic, that lead to reusing some
temporary buffers which contained garbage;
- the versatile gl buffer implementation so that it now properly
switches between the RGBA_Image and the FBO content (yes, this
is insanely slow and inefficient... but it works and that was
the only point).
Alright, so this is a massive patch that is the result of
trying to get rid of unused or poorly implemented classes in
ector. Originally ector was meant to support VG but extend to
things like filters as well. At the moment, ector's design
makes it quite hard to plug in the filters.
For now I think it's easier to implement the GL support for
the filters directly in the engine, where I hope to interfere
as little as possible.
This massive patch keeps only the required minimum to support
a versatile gl buffer that can be mapped, drawn or rendered to (FBO).
It's extremely inefficient as it relies on glReadPixels and lots
of texture uploads, as well as conversions between ARGB and Alpha.
Another type of GL buffer is a wrap around an existing GL image,
but that one is read-only (map or draw: no write map, no FBO).
No, all the filters run fine, and the high-level implementation
(evas_filters.c) does not need to know whether the underlying engine
is SW or GL. One problem though appears with the blending or blurring
of some Alpha buffers, the colors are wrong.
This patch removes more lines than it adds so it must be good ;)
This is an attempt at refactoring the filters code so I can
later implement GL support. This patch adds a few extra changes
to remove avoid calling functions of libevas from the software
engine: use the draw functions from static_libs/draw rather
than evas_common APIs.
Summary:
Before, rsc->current_ctx is always same with ctx.
So checking context change was meaningless.
From now, it has meaning.
Test Plan: App call evas_gl_make_current more than twice in pixels callback. Those surfaces are indirect rendering surface.
Reviewers: jpeg, dkdk, wonsik
Reviewed By: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4773
Summary:
If the last item before ellipsis item has bigger width than its advance,
evas_common_font_query_last_up_to_pos() function can find wrong ellipsis position.
When Evas finds a position for non last item, Evas must care about additionally
available space for glyph's width of the given x position.
ex) the last item's glyph before ellipsis item has a tail to draw above the ellipsis item.
@fix
Test Plan:
Test case will added as comment.
(Becasue of font license problem.)
Reviewers: herdsman, raster, jpeg, woohyun
Subscribers: cedric, Blackmole
Differential Revision: https://phab.enlightenment.org/D4727
Summary:
eina_file_virtualize is causing issues.
memfile_set is better but see attached bt.
What to do???
Reviewers: raster, cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4743
the code added by minkyoung has a definite security flaw here trusting
e->response to be within a small range when all it is is an int -
range is not limited other than that... so fix the code to check for
range like further code below does.
this commit went in 2 days ago... so not an existing bug fix.
The things you learn to love...
The situation was:
- An object is mapped (naviframe in an animation)
- One of its children has a mask
- The window is rotated by 90 or 270 degrees (landscape)
The mask glsl code to invert the x,y coordinate depends on the
screen rotation and this somehow was wrong.
Tested on Tizen and in elm_test "Masking", made with @jiin.moon.
@fix
Summary:
This prevent invalid shared memory access.
Invalid access occur when server is resized sequentially from now to A-size
to B-size, and client receive A resize message after resizing B.
Then client try to render plug image with A-size, but shared memory is B-size
buffer. Size are mismatch. This makes segmentation fault when uploading texture(gl)
or rendering image(sw).
Test Plan: Indicator rendering on Tizen3.0 platform.
Reviewers: jypark, wonsik, dkdk, scholb.kim, jiin.moon, jpeg, cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4711
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
If we don't have EGL_EXT_buffer_age then we don't have buffer age - it's
a completely independent extension to KHR partial update.
This partially fixes partial update on recent mali drivers.
I believe there's a limitation in libglvnd where it doesn't
propagate the calls to eglGetProcAddress() properly to the vendor
library.
See also 265c851a8f
It seems OSMesa was recently updated to not expose symbols statically,
so dlsym() returns invariably NULL. GetProcAddress must be used. Note
though that the extension "EGL_KHR_get_all_proc_addresses" is not
present (OSMesa is OpenGL, not GLES), and there is anyway no list
of extensions in OSMesa (at the WSI level, glGetString() returns a
ton of GL extensions as expected).
My OSMesa version is 11.2.0 (mesa 17.0.1).
This fixes make check.
@fix
Derek Foreman
Carsten Haitzler
Jean-Philippe Andre
Cedric BAIL
Minkyoung Kim
Youngbok Shin
Al Poole
Mike Blumenkrantz