Summary:
it FINALLY happend! With this python bindings should be able to work
again with a meson build, you can also enable b_lundef right now. And it
appears to work, with this we can also get another step closer to a
windows build.
Depends on D8669
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8670
Summary:
with this we don't have any static module anymore in the engine
directory. This means either *all* modules in the enignes directory are
static OR shared. There is no mixture anymore. This is a requirement for
the directory to be build whenever we want it to be build.
Depends on D8667
Reviewers: zmike, stefan_schmidt, cedric, vtorri
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8668
warnings now are being super picky with:
../src/modules/evas/engines/software_x11/evas_xlib_buffer.c: In
function ‘evas_software_xlib_x_output_buffer_new’:
../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:306:56:
warning: cast between incompatible function types from ‘void
(*)(Display *, XErrorEvent *)’ {aka ‘void (*)(struct _XDisplay *,
struct <anonymous> *)’} to ‘int (*)(Display *, XErrorEvent *)’ {aka
‘int (*)(struct _XDisplay *, struct <anonymous> *)’}
[-Wcast-function-type]
ph = XSetErrorHandler((XErrorHandler)
can we really match a struct <anonymous> somehow? i don't think so...
so... void to the rescue.
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
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
One deadlock and one segfault.
Patch 1:
Software X11 Evas Engine: Fix deadlock
Summary:
The patch bc6e8d2692 introduced a callback responsible to notify the pixels
that were sent to the X server. Since all EFL rendering is done by another
thread, the callback should be called from the main thread context.
To achieve this behaviour evas_software_x11_region_push_hook_call()
was using ecore_thread_main_loop_begin(), which may cause deadlocks, since
evas mainloop waits for the render thread and the render thread waits
the mainloop.
In order to fix this problem, the function
ecore_main_loop_thread_safe_call_async() will be used to
schedule the callback to run in the main loop context.
Since a callback is schedule to run in async manner, the pixels that
were sent to the X server must not be deleted until the user is informed.
In order to avoid more mallocs(), this patch adds the support for refcounts to the
X_Output_Buffer and Xcb_Output_Buffer.
Patch 2:
Ecore_Evas VNC: Use the image size to create the buffer.
In same cases they may differ and may lead to a segfault, since
memcpy() causes a buffer overrun.
Reviewers: bdilly, raster
Reviewed By: raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4323
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.
this is quick to get evas working again. this disables part of
7e2d700d06 that creates deadlocks. this
thread waits on mainloop. mainloop waits on this render thread. BOOM.
deadlock.
To properly implement EGL_KHR_partial_update we need to know the buffer
damage before any drawing operations take place. Add a new callback to
software_generic that takes place after combining of surface damage and
swap mode when we actually have this available.
Note: This means the three copy pasta implementations of
EGL_KHR_partial_update scattered around the tree are all wrong. bummer.
so our sysv shm segments were both over-permissive (nothing bad
really, just other users could read and write to/from our pixel data
destined for the screen... they could do this to x11 directly anyway
so no real issue), but be more restrictive and use 0600 as xserver
runs as root so can read/write anyway and we only want our own uid
access. but even more - fix our shm segment flushing to not keep lots
of segments floating about like a bad smell when we don't need them.
we had a cache but it wasnt flushed when it should be since async
rendering turned up. this fixes that and we're back to agressively
flushing them out when idle.
@fix
Summary:
1. For converting tbm buffer from yuv to rgb, image.data should be allocated.
2. Stride should be set by info of tbm surface.
3. The number of row is height*2. but if height is odd, last row is invalid in process of _evas_video_i420.
Test Plan: Local Test, Tizen2.4 Mobile
Reviewers: spacegrapher, wonsik, jpeg
Subscribers: cedric, dkdk
Differential Revision: https://phab.enlightenment.org/D3870
This follows commit f10672dd74
which apparently forgot some changes in xlib and eglfs.
I hope there are no remains of the old native bind/unbind
functions. Also... I can't build everything, so I'm just hoping
this works. Note: GL and SW native images are not using the
same internal api prototypes.
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
- image_native_init
- image_native_shutdown
init() will be used to test whether the engine supports a
certain type of native image.
Note: Native image support is very much dependent on the engine,
and some stuff like opengl should work everywhere (even in sw
with osmesa) but that's not the case.
Summary:
Add TBM surface in wayland and clean up Native struct on Evas Engine.
Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend.
This patch has the code for wayland backend.
In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common.
And, Native in Evas_Engine is clean-up.
@feature
Test Plan:
TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device.
Pixmap surface is tested in ubuntu with same test app.
EvasGL is tested with elementary_test.
Reviewers: jpeg, spacegrapher, raster, cedric
Subscribers: dkdk, scholb.kim, JoogabYun
Differential Revision: https://phab.enlightenment.org/D3501
We have to use void in a function declaration if we want no function
parameters. Using just empty parenthesis means the function takes an
unspecified number of parameters.
We had it correct for most declarations and this series fixes it for
the rest.
If we end up leaving evas_xlib_image_dri_native_set due to a failure
to allocate memory, we should free the previously allocated
Evas_DRI_Image so that we don't leak
NB: Fixes Coverity CID1339782
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
evas_xlib_image_dri_native_set should be returning a pointer to an
RGBA_Image on success, or NULL on failure. Returning EINA_FALSE here
leads to an expression which evaluates to zero being treated as a null
pointer constant
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Marcel Hollerbach
Carsten Haitzler
Chris Michael
Marcel Hollerbach
Cedric Bail
Prince Kumar Dubey
Mike Blumenkrantz
Jean-Philippe Andre
Guilherme Iscaro
Derek Foreman
Tom Hacohen
Stefan Schmidt
Minkyoung Kim
Wonsik Jung