This is very useful to specify precisely which kind of RGBA -> Alpha
conversion you want. If all you wanted was the alpha layer to use as a
mask, set this flag to true.
@feature
Summary:
The Encoding key is no longer required, all desktop files are assumed to
be UTF-8 encoded. See details at:
https://standards.freedesktop.org/desktop-entry-spec/1.1/apc.html
Fix various typos and misspellings
lintian, Debian's package checker, uses strings to check for common typos
in compiled binaries. This change fixes the ones it identified in 1.20.6.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5584
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Coverity reports passing a null pointer 'im->gc' to
evas_gl_common_context_flush which directly dereferences it, so lets
be sure that 'im->gc' is valid before passing it to context_flush
Fixes CID1374273
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports that there may be a null pointer dereference here so
check that 'error' exists before trying to set it.
Fixes CID1374272
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
A recent commit broke texture_from_pixmap for NVIDIA EGL
(again), because eglCreateImage is a symbol in libEGL.so
but isn't in fact implemented by the driver.
That's because eglCreateImage() is exposed by libglvnd but
the underlying EGL implementation is NVIDIA and its version
is only 1.4, not 1.5 (where the API was introduced as core).
Instead of reverting the patch, it's better to cover our
bases properly and use dlsym() only if the version is right.
Note that GetProcAddress() may return garbage function
pointers for ALL functions as dynamic virtual functions may
be created on the fly by libglvnd. So it is absolutely
necessary to check the extension string as well.
See 0255f14dc2
eglCreateImage is objectively better than eglCreateImageKHR - it allows
attributes large enough to hold pointer values. We should use it when
available and only use the older extension version as fallback.
Also, eglCreateImage is core EGL functionality so don't depend on extensions
to be present to use it. Theoretically we should be testing for
EGL version >= 1.5 but it's probably safe not to.
This was only necessary due to bugs in the wayland_egl and gl_drm engine
that have been corrected.
Wayland has no bizarre requirements making this necessary.
These aren't a thing. the GL_OES_EGL_image_base extension doesn't exist
and the GL_OES_EGL_image extension doesn't extend egl, because it's a gl
extension.
So let's stop being the only google match for these nonsense strings.
this fixes an issue that has cropped up in the past few months - only
nvidia drivers with egl/gles in x11... and compositing won't work
(native surface) and the introduction of libglvnd
it's a combination of libglvnd lying that it has symbols it can't
later find, new features to get core functions via procaddress that we
hadn't migrated to use AND use preferring core functions that libglvnd
will expose, so switching to KHR extensions by preference. we also
need to symmetrically use destroy image khr too...
oddly enough using procaddress purely for create/destroy image makes
wayland fail ... sofor now i'm taking advantage of the fact that
wayland has no extensions string passed in at the moment and still
doing dlsym... this is odd though.
@fix
Summary:
Summary : String buffer returned by eina_strbuf_new() is not freed in some cases
@Fix
Signed-off-by: Uma Devika <u.bodapati@samsung.com>
Reviewers: cedric, tasn, jpeg, raster, singh.amitesh
Subscribers: tanwar.umesh07, yashu21985, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5000
Set this env var to "300 es" to test GLSL 300 ES as shader
version. This is for brokenshakles.
Example:
export EVAS_GL_GET_PROGRAM_BINARY=0
export EVAS_GL_SHADER_GLSL_VERSION="300 es"
export ELM_ACCEL=gl
elementary_test
Omg... Thanks Daekwang Ryu for pointing me to my error. I remember
struggling a lot with this OpenGL API and libGLdispatch (glvnd) when
in fact this was all just a typo in the code.
GLES 3.1 and the upcoming 3.2 support need a proper test case...
See c68a409874
@fix
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 ;)
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
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
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
If GL context is free'd before processing font shutdown,
textures for emoji glyph's GL images will be free'd without clean
up its GL images. It causes eina mempool infinite loop issue when
emoji's GL images are free'd in shutdown process.
So, the patch will make a list for emoji's GL images in context and
clean up them when the context is free'd. Just like font textures in
context.
@fix
Differential Revision: https://phab.enlightenment.org/D4695
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
It was assumed that GLES 3 would only work with EGL but in fact
OpenGL 4.3 & 4.5 are supersets of GLES 3.0 & 3.1 respectively. So
GLX should also support GLES 3.0 or GLES 3.1 for evas gl, if the
driver supports it, of course.
Of course while doing this patch things didn't go like they were
supposed to go. I'm currently using NVIDIA's proprietary driver,
that conveniently provides EGL with GLES 3.2. But wait, there's
a catch: GL_VERSION is "OpenGL ES 3.2 NVIDIA" except that none
of the functions of GLES 3.1 or GLES 3.2 are actually supported.
Those functions are only present in the GLX/OpenGL variant of the
driver. Thanks so much for making my life easier...
So yeah, this patch contains a hack for those invalid versions
of GLES 3.x. What was supposed to be a small fix became a huge
mess.
Also add a comment about the possibly invalid auto-upgrade from
GLES 2 to GLES 3.
This adds a test case in elm_test, but only to verify that
elm_glview_version_add(3) actually works. We need a proper GLES 3
test case, eventually (and 3.1, 3.2 of course).
I believe that all the threads created in our test suite should
be spawned without any special CPU affinity. The default parameter
is not 0 (corresponds to the first CPU, known as CPU 0) but -1.
Similarily the default priority is NORMAL (1), not 0 (URGENT).
This also affects two unused code paths: evas render2 and gl preload.
@fix
This should fix an ERR message under gl_drm and probably an
actual bug.
This reverts 8f2cfdf490.
I don't think the texture target should be part of the context
information. It should instead be a property of the texture.
Fixes T5171
See b16c961680 which by "fixing" indentation changed the
logic of the code. Yes the indentation was misleading (because of
the #if / #else) but the logic was correct. Anyway this is was not
a harmful issue as those memory trackers aren't really used.
gcc reports that the 'else' here does not guard the latter
statement...seems like a cause of some missing parens so fix.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
MSAA (multisampled_render_to_texture) support was implemented with
GLES 2 in mind, but for GLES 3 it comes as a core feature, not as
an extension. Also it relies on renderbuffers, not textures. GL
is awesome.
Note: MSAA still doesn't work!