Including certain headers in the wrong order can cause problems if
we're configured to use beta api (right now wayland forces this).
In most cases we should just be including e.h and not the individual
EFL headers anyway. This fixes some of that.
fix T3426, T3428
Wayland buffers are currently either ARGB or XRGB - we don't need to
convert either of these, we just need to set alpha appropriately - which
we now do.
We need to keep wayland buffers around even if they'll never be written
to again. This is part of Buffer_Reference's task in weston, but we
already have our pixmap abstraction which can serve mostly the same
purpose.
Remove the "buffer reference" stuff from e_pixmap and replace it with a
kept buffer for the last commit.
Add shared memory pool references to keep pools from going away on us.
using pointers for this turned out to have some corner case collisions, so
now just use something totally unrelated to the surface to ensure uniqueness
The resource destroy callback for frame callbacks will walk the frame list
to remove itself. When freeing that list we need to make sure the
resource destroy callback doesn't see the same list we're walking and
corrupt it.
due to how deferred rendering works, it's possible for a client to
send a second buffer before enlightenment has rendered the first one.
in this situation, it seems that the best solution is to queue successive
buffers (frames) and pop the queue after each render
ref T2784
the previous methodology was effectively:
attach -> ref(new buffer) x2 / unref(old buffer) x2
...
...
attach -> ref(new buffer) x2 / unref(old buffer) x2
this resulted in buffer management failures and crashing. now the
buffer gets 1x ref before render and 1x unref after render, ensuring
that the lifetime is accurate (assuming evas doesn't lie to us)
now we still have random crashing during resize, but not as much as
before
moderately certain I originally wrote this to work in the other direction
and then failed to remove it when I switched to setting parents instead of
children. regardless, pixmap hash should not be changed here
This reverts commit b41dbbe9cf.
Revert this ... it works, but it's not the "proper" fix as it just
causes the crash(s) to happen elsewhere ... time to dig deeper
This was a cause of some memleaks/crashes in the wayland compositor
because the compositor was trying to access properties of the E_Pixmap
after it had already been freed. By setting the user_data to NULL, the
functions in the compositor which were failing will now stop trying to
access the pixmap after it's been freed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: this patch will provide to launch the application based on XRGB8888 like weston-simple-shm.
Test Plan: launch weston-simple-shm
Reviewers: devilhorns, zmike, raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D1137
NB: Each different build (x11/wl-only) had various unused variables.
This is a squash of the commits to fix all that.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Derek Foreman
Mike Blumenkrantz
Chris Michael
Stefan Schmidt
Carsten Haitzler
Seunghun Lee