This has been a stub for a long time, but now we have a native_set, so
we should have a native_get too.
This is required for hw plane usage on the software engine.
Functions to assign a plane for a native surface, and release a plane
that's been assigned to a native surface.
These are empty for now as they'll need to be overridden in any backend
that can handle planes.
This patch adds support for updating ecore_wl2_window stack mode when
the ecore_evas_layer_set is called.
"#divergence"
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds support for ecore_evas_focus_skip_set in the wayland
engine.
"#divergence"
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so modern systems seem to have abandoned rgb.txt files. this leads to
us breaking the loading of xpm files tha use color names ... i added
the rgbt.txt from vim but that didn't seem to help... odd... so to just
stop adding path after path to load... ship our own. we could ship the
file... but then we'd still have to load and parse it... every time we
look up a color. so i munged the data with awk and now we compile it
in. it should consume the same space the rgb.txt does in the shared lib
binary. if not read it shouldn't be paged in. it should end up cheaper
than our floaing of the file and mmaping it when xpm module is
loaded/initted... so either way more efficient, uses a little less ram
(12306 bytes vs 17780 for the rgb.txt) ... and bonus - dont have
an extenral out-of-code data blob to find, manage install etc...
this means we should load xpms with colornames correctly again on
systems without an rgb.txt provided by x11 ... which seems to be the
common case now. :(
@fix
This patch adds function pointers to the Wayland Interface that can be
used for supporting auxiliary hints on a given window
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
As we will now use static_libs/libdrm for building ecore_evas_drm, we
no longer need to include this bit of borrowed four_cc code from libdrm
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds support to Ecore_Evas_Wayland for Window Manager
Rotations so that window managers which do support rotations are able
to rotate an EFL wayland application.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
2 more. /etc/X11/rgb.txt /usr/share/vim/vim80/rgb.txt ...what i do notice
is that this file seems to have vanished from modern systems... so we'll have
lots of un-fun loading old xpm's with colornames if we cant figure out what
color names map to what colors...
If/When we exit _evas_outbuf_egl_setup function, we should be freeing
the allocated cfgs variable else we leak it.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
As we won't get a request from a server to raise a window which is not
visible anyway, this check is useless.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
_ecore_evas_wl_common_new_internal() creates both wayland_egl and
wayland_shm backed windows, so reporting that the failure was in looking
up "Wayland_Shm" could be misleading.
Also, this routine can be called with any arbitrary string as
engine_name, so including what was received in the error message might
be helpful for diagnosing bugs.
Reviewers: cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4897
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Coverity reports an error "Calling "xkb_keysym_to_utf8" without checking
return value (as is done elsewhere 4 out of 5 times)."
fixes: cid1375673
Reviewers: zmike
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4936
This is a quick and harmless hack to make sure we don't come back to a
dead compositor on a vc switch.
A proper fix will follow eventually, I promise.
Really. Would I lie?
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
this is still semi-broken if a seat has many pointer-ish type devices since
pointer devices in ecore-evas were never correctly implemented to be 1:1 with
seat:cursor relationships
@feature
windows do not have pointers or cursors under wayland, seats do. due to
lack of multiseat support, most components simply use the "default" seat
with these functions, but this should make the corresponding code more
easily adaptable
the current (v6) xdg-shell spec reads as follows:
Client window decorations should be painted as if the window is
active. Do not assume this means that the window actually has
keyboard or pointer focus.
so this is not equivalent to receiving/losing input focus and should not
be propagated as such
@fix
Removes the previous "busy" flag, as now we might have an fb attached to
multiple outputs at once, and need to be careful to destroy them only
after they've been removed from all outputs.
Removed the old "busy_set" API which nothing used, and renames fb_destroy
to fb_discard to make it more clear that it's not immediately destroyed.
It's all beta api, so I can do this.
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
Somehow this long standing bug wasn't obvious until wayland 1.13.0 made
some additions to an opaque structure.
This changed the frequency that new buffers came to us with the exact
same pointer value of a buffer that had just been freed.
This shortcut in eng_image_native_set has always been wrong - we need to
proceed to the end to make sure we pick up new dmabuf attributes.
This fixes fullscreen feature in Elm on Windows as the geometry of the desktop
was not known.
In case of multiple displays, the desktop, where the window is displayed, is used for fullscreen.
@fix
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Evas can't open tiff file because of no implement in client read api.
I wrote codes simply for open.
Test Plan: self
Reviewers: jpeg, cedric, jypark
Subscribers: stefan_schmidt
Differential Revision: https://phab.enlightenment.org/D4857
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
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
This reverts commit dfb1877500.
This did fix the problem of "rage -f" not starting properly, but it
broke toggling between fullscreen and !fullscreen for other apps.
They'd resize to a large, but not quite fullscreen, size, then render with decor
present, and big black bars on the right/bottom edges (which were offscreen due
to the client size and position)
This isn't really the right place to fix this - it's a protocol usage bug, not
a canvas bug.
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
Currently, ecore_evas_extn only use exclusive lock.
so if there are many ecore_extn_plugs , there is competition among the ecore_extn_plugs.
since the ecore_extn_plugs dont need to use exclusive lock, add the shred lock mode.
We need a display unset path for software render to prevent an async
render completing after a disconnect from posting a frame and crashing
us.
As of this commit both software and gl session recovery work for me.
fix T5005
#SessionRecoveryWorksHere
Calling ecore_wl2_window_surface_get() has the side effect of creating
a new wayland surface if we don't already have one. If we do that
during a session recovery, we can try to create a new surface while
we have no connection to a compositor - that's Bad.
So we just use the one we already have stored - which we NULL out on
disconnect.
When wayland session recovery happens, we can end up down this path
with no gl context when elm reprocesses its config file.
That callback fires long before we've re-set up our wayland connection
so we can't possibly have a valid gl context yet.
Prevent that from crashing.
64 bytes in 1 blocks are definitely lost in loss record 152 of 258
at 0x4C2AB80: malloc (vg_replace_malloc.c:296)
by 0xC786A77: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
by 0xC78747B: _XimDecodeIMATTRIBUTE (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
by 0xC77A7EF: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
by 0xC767771: XGetIMValues (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
by 0x113CFE09: ???
by 0x113D08F7: ???
by 0x83DD329: ecore_imf_context_client_window_set (ecore_imf_context.c:240)
by 0x530779D: _edje_entry_real_part_init (edje_entry.c:2937)
by 0x5311C20: _edje_object_file_set_internal (edje_load.c:1079)
by 0x5328665: _edje_object_efl_file_mmap_set (edje_smart.c:438)
by 0x775BD3A: efl_file_mmap_set (in /usr/local/lib/libefl.so.1.18.4)
commit 81783ec75c combined two "identical"
pieces of code that weren't identical. The removed code never checked
if the evas was visible before performing operations to make it so,
the code left behind would bail if the evas was visible.
Reset the visible status during disconnect to make sure we properly show
windows after a session recovery.
ref https://phab.enlightenment.org/T5005
@fix
Session works on the software engines at this point. Use this as a bisect
point next time someone fubars it.
GL still broken. Window geometry seems like it doesn't get updated right
either, but at least clients reconnect again.
#SessionRecoveryWorksHere
As we already call the same functions inside
_ecore_evas_wl_common_show, there is no need to duplicate the same
code when we have defer_show set...just call the show function.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Calls to make a window fullscreen do require the window to already
have a shell surface with which to fullscreen. If an app sets the
window fullscreen property when the window is not shown yet, then the
app would never startup fullscreen. This patch fixes that issue by
adding a 'defer_fullscreen' flag to Ecore_Evas (wayland) so that when
the window does finally get shown, we can show it in fullscreen.
Addresses part of the T5044 ticket...
ref T5044
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Avoid calls to zwp_text_input_v1_set_cursor_rectangle if we do not
need to. Previous code here would always call this function even if
the cursor rectangle was in the same position. Now we set a flag on
the cursor_location field to let us know that it needs updating.
ref T5226
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
wayland_imcontext.h already includes this header, so no need to
re-include. Also add missing (void) to function declaration
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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
Small patch to not call _ecore_evas_register unless we are showing the
window. This stops creation of rogue animators on cursors until the
window is actually going to be shown.
Fixes T5209
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
==1321== 156 bytes in 1 blocks are definitely lost in loss record 7,687 of 9,703
==1321== at 0x4847E64: calloc (vg_replace_malloc.c:623)
==1321== by 0x92EA7E9: wayland_im_context_new (wayland_imcontext.c:1094)
==1321== by 0x92E66DD: im_module_create (wayland_module.c:132)
==1321== by 0x4D521E7: ecore_imf_module_context_create (ecore_imf_module.c:152)
==1321== by 0x4D51EF7: ecore_imf_context_add (ecore_imf_context.c:141)
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.
If we are in async render and a call to rotation_set has been made,
then we should delay setting that rotation until rendering is
completed. This patch fixes that issue by setting ee->delayed.rotation
and handling it during _drm_render_updates
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we are in async render when a call to set rotation happens, we
should not be setting the engine info->rotation until we have actually
handled the rotation. Old code here would set delayed.rotation on the
ecore_evas itself, but then it would tell the engine to rotate. What
we actually want here is If in async render, set the delayed rotation
property and let render_updates deal with any delayed setting.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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!
Summary:
glFramebufferTexture2DMultisampleEXT() supports color attachment only.
so depth&stencil attachment should be bound via renderbuffer not texture.
According to http://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt
In order to allow the use of multisampled depth and stencil buffers
when performing multisampled rendering to a texture, the extension
also adds the command RenderbufferStorageMultisampleEXT.
target, textarget, texture, and level correspond to the same
parameters for FramebufferTexture2D and have the same restrictions.
attachment must be COLOR_ATTACHMENT0.
Test Plan: Evas GL on GLES 3
Reviewers: jpeg, raster, dkdk, wonsik
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D4648
Derek Foreman
Jean-Philippe Andre
Chris Michael
Carsten Haitzler
Amitesh Singh
Thiep Ha
Cedric BAIL
Bryce Harrington
Mike Blumenkrantz
Vincent Torri
jiin.moon
Stefan Schmidt
Minkyoung Kim
Youngbok Shin
Al Poole
Jean Guyomarc'h
Jiyoun Park
Jihoon Kim
Godly T.Alias