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
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
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 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 ;)
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).
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!
newframe() resets some of the gl context properties, so match them
to our shadow copy in the gc state.
target_surface_set() also resets some of those properties but only
in our shadow copy, not in the actual GL context. As a consequence
we can't rely on setting a bool to 0 or 1 unless we also call the
equivalent GL function. Expand bitfields to 2 bits allows us to
set a bool to the invalid value of -1 (yes, that's not a real bool).
Also there is no need to reset the target surface to NULL during
newframe. It will be reset during target_surface_set.
This fixes some issues I encounter while working on GL filters.
we use invalid values (-1 or 0xff or 0x3 etc. invalid vals to know to reset
some state). expand fields out in size a little bit to allow that to
work again.
this reduced pipes to 32 as default max pipes is 32 and we never
actually go up beyond 32 unless oyu use env vars to expand... and no
one will... and actual testing shows us top out at about 30 pipes
usage in anything i can find/test. this packs more bool flags together
as bits instead of itns or chars to save memory.
@optimize
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
for gl noscale buffers are texture atlases that are fbo's. the point
is never to scale or transofmr them but to render them pixel for pixel
and just store pre-rendered data where its cheaper to do this than
rebuild every time. this is the enigne infra for sw and gl with the gl
code... it SHOULD work... in theory...
The first patch did not work for maps. This explains why the
original code was so weird. But it actually made sense.
After struggling a bit I realized that we really just need
to shuffle around the pixel position on the window to map that
of the position in the canvas (unrotate it).
Note that compatibility with GLSL-ES (for OpenGL ES) implies
we can not use an array initializer like:
vec2 pos[4] = vec2[4](a,b,c,d);
So the code could probably be optimized. But at least this works.
This patch also avoids calling glGetUniformLocation again and
again.
So ok. haha. Amusing. But this is inappropriate.
1. It's not an INTENDED effect in theme so unless the theme ius doing
it - it shouldn't happen.
2. There are places to do this and it's NOT inside an engine. There
are high level filter and other mechanisms.
3. Actually this shouldn't be even done client-side. It should be done
compositor-side when moving a window around. Knowing velocity vector
etc. is useful to a client so the protocol can stay but doing the
animation client-side is "wrong". Some windows wobble and others do
not based on toolkit? really? sure we have to live with the CSD
difference but this? The compositor can do this JUYST fine. leave it
to compositor... OR do this properly with filters client-side. e.g. a
2d displacement map with evas filters would do the job as long as it
interpolates. If you want a way of forcing ALL objects in the canvas
to redirect to an intermediate buffer then do it up there at the
canvas level. It then works in GL and software, as opposed to only GL.
Also.... this is now causing issues for users:
<memeka> hi, from
https://git.enlightenment.org/core/efl.git/commit/?id=fb76fe55a52ac212b6870f1d74470a79ea5c5246
i run EFL_WAYLAND_DISABLE_WWW=1 terminology -> but it crashes in
wayland_egl/www.c in the setup_shaders function .... HELP?
so the fun was fune until we do a release (now) and until this causes
problems for users. Back to tried and tested code.
If you want to do this... do it right at the portable layers above.
...
Revert "wayland-egl: Fix use after free"
Revert "wayland_egl: Fix redirect to texture"
Revert "evas-wayland-egl: Add www protocol handling to wayland-egl engine"
Revert "gl_common: Add API for redirecting render to texture"
This reverts commit 2760afbb0e.
This reverts commit c937248eac.
This reverts commit c67f50b40a.
This reverts commit 0f7f4b6de0.
An unknown crash happened in glDrawArrays() where color_ptr is
a non-reachable pointer that looks like a valid malloc() zone.
Unreproducible issue. I can only hope this patch doesn't actually
break anything.
This cleans up rectangle and line in particular, that were not
using common code to use GLPIPES. I honestly couldn't find a
problem though.
Previous redirect to texture approach broke multiple window applications
by having only a single redirect per context. This approach allows
multiple redirections.
New API allows a context to be redirected to texture. When rendering is
complete the texture can be unbound from the frame buffer and used for
post-processing effects.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Summary:
Evas Image should be independent of render engine.
So remove native.func.data member of RGBA_Image, Evas_GL_Image struct.
And remove data argument,too.
Test Plan: Local test, Tizen3.0 mobile, Desktop englitenment
Reviewers: jpeg, spacegrapher, wonsik
Subscribers: cedric, dkdk
Differential Revision: https://phab.enlightenment.org/D3850
Summary:
If 2 evases refer to same pixmap, use same EvasGL_Image.
But EvasGL_Image can have only one engine data.
When evas related to native is destroyed and another evas use that native, crash occur.
So native callbacks need to be independent to engine data.
Test Plan: mobile, local test
Reviewers: cedric, spacegrapher, wonsik, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D3800
This would be cleaner than adding it as a suffix to the filename.
Use simple write and read_direct for simplicity.
This is an improvement on 3dcd903a53 and should make sure
everyone is actually using the latest version of the shaders even
if they track master or the alpha/beta releases.
Since we now have only two shader strings, this is trivial to do:
hash the strings and add them to the cache filename.
This will allow people using 1.17.0-alpha, etc... to discard their
old shaders cache automagically and use the latest version of the
shaders (because alpha is not in the filename).
If we end up adding more runtime generated shaders, we might need
a better strategy, but this should be good enough for now.
Dumb implementation of a "smart" buffer capable of wrapping an
RGBA_Image but that can still be rendered on screen (ie, an
Evas_GL_Image is attached to it).
This is the kind of horrible things you'll encounter when working
with GL. The surface and context need to have matching configuration
otherwise make current will fail, and the only way to get a matching
config is to reuse the config selected to create the context. Gah.
This is the same fix as for EGL. More a hack than a fix, to be honest.
@fix
egl images created using tbm surface for native surface set use
GL_TEXTURE_EXTERNAL_OES as texture target, so we should bind to
this target when rendering.
Dynamic hint set using tbm surface also creates egl images, but
as we only use RGB* colorspace for this we can use GL_TEXTURE_2D.
So, keep track of texture target in shader array, and bind to the
appropriate one.
This also fixes the bug that image_data_get only worked when BOTH
sec_image_map and sec_tbm_surface extensions are supported.
Summary:
Dynamic hint set using tbm surface can only be used when EGL_TIZEN_image_native_surface
extension is supported by the driver. So check for both tbm surface and egl extension.
Summary:
I found some bugs in EvasGL with OpenGL ES conformance test.
6 wrapper functions are added for GLES2,
(glDeleteFramebuffers, glFramebufferRenderbuffer
glFramebufferTexture2D, glGetError
glGetFloatv, glGetFramebufferAttachmentParameteriv)
3 wrapper fucntions are added for GLES3.
(glDrawbuffers, glGetStringi, glReadBuffer)
Test Plan:
GLES3 sample app,
EvasGL(OpenGL ES CTS) for 2.0 is passed.
For 3.0, 10 TCs are failed (Total : 2994TCs).
Reviewers: wonsik, spacegrapher, jpeg
Subscribers: cedric, JoogabYun, scholb.kim
Maniphest Tasks: T2621
Differential Revision: https://phab.enlightenment.org/D3301
Youngbok Shin
Cedric BAIL
Jean-Philippe Andre
Carsten Haitzler
Derek Foreman
Subhransu Mohanty
Nicolas Aguirre
Minkyoung Kim
Vincent Torri
Dongyeon Kim
DaeKwang Ryu