so getting context at least on some dviers is expensive. it may really
impact cpu usage a lot (in this cate getpid() was being called by the
nouveau drivers and that can be expensive. it is on ARM as it's a full
syscall and 1-2% of cpu time was just getting pid all the time thanks
to this...
@opt
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
this has been going on for a while. on nvidia drivers in gles mode on
x11 there is a massive perf drop to like a few fps with enough windows
if we build for egl/gles instead of opengl. it was the re-creating of
eglimages every frame. put a vendor specific workaround for this and
avoid it. it's not needed there anyway. framerate back to 60fps
smoothness afterwards.
@fix
Summary:
this is a longstanding issue which was exposed by recent patches to standardize
object lifecycles. when a native surface is used by multiple images, unsetting
the surface from one image must not destroy the native surface or else the
remaining images
fix T6970
@fix
Reviewers: ManMower
Reviewed By: ManMower
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T6970
Differential Revision: https://phab.enlightenment.org/D6235
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>
gl_generic_context_find() returns the gl shared context struct but
this is not just a read-only operation. It in turn calls window_use
which may call make_current. This can invalidate the work of evas gl
when the API tried to switch to a specific context.
This fixes evas gl with multiple outputs.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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
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).
If someone's trying to build efl git with 2.5 year old EGL headers they get
a break on missing EGLImage...
We should probably consider keeping an up to date copy of the EGL headers
in efl. There may be someone out there with even older headers.
There's actually an array of 2 in gl_x11, but it appears we only use the
first 1, except in an #if 0 block.
I gather this is legacy for some reason - it sure doesn't seem to make
any sense now, so I'm chopping off all the extra array indexes.
Note: I've not changed gl_sdl - it looks like it doesn't use the context
or surface at all and they could just be removed, but I don't build that
one here and don't want to touch it.
Thank you NVIDIA for breaking your drivers regularly!
eglGetDisplay(x11_display) should work but was consistently
returning 0 instead.
Apparently EGL 1.5 introduced "eglGetPlatformDisplay" that
is more advanced to open a display. So, prefer that over
eglGetDisplay if it's available.
@fix
this will define EGL_WAYLAND_PLANE_WL and EGL_WAYLAND_BUFFER_WL if
missing as SOME older egl public headers dont expose them and yet we
still wans to compile and support the feature should the egl BINARY
etc. actually support this (or be upgraded to support it after efl
compilation).
@fix
this technically isn't needed. it does help in some cases hide driver
or other buffer swap bugs, but in and of itself is not needed, so
remove. at least the drm egl bugs still happen on my pi3 so its
something else...
KHR partial damage must be set once at the beginning of rendering with
buffer damage for the entire scene to be rendered. Doing otherwise can
result in graphical anomalies on some GL implementations.
Some engines should using sending surface damage, until now we'd only ever
provided them with buffer damage.
The difference is that surface damage is the damage to the surface the
compositor is displaying, and the buffer damage is the damage to the
buffer the client has rendered. These are different when the client
is using multiple buffers of different ages to render into.
Anything that calls eglSwapBuffersWithDamage, wl_surface_damage() or
wl_surface_damage_buffer() should be using surface damage, and not
buffer damage.
This patch is intended to make no functional change - any flush cb that
used buffer damage before still should. Actual fixes to follow.
Apologies if I broke any engines - it's a bit of a copy and wasteland
out here.
eglCreateImage and eglCreateImageKHR have different parameters - the
attribute list is EGLint for one and EGLAttrib for the other. Since
EGLAttrib is long, on a 64-bit system it's a different size than EGLint.
This was causing a crash in Enlightenment's wl_x11 on 64-bit machines when
trying to use a gl client.
Add a thin wrapper to use whichever is available and pass the appropriate
sized data.
Carsten Haitzler
Marcel Hollerbach
Chris Michael
Mike Blumenkrantz
Ross Vandegrift
subhransu mohanty
Cedric BAIL
Jean-Philippe Andre
Derek Foreman