osmesa needs llvm. llvm apparently just by dlopening or linking to the
lib (libLLVM...) gets you 3.5mb of dirty pages just in this lib. that's
a whole lib entirely dirty pages. odd and horrible. in fact once i
stoppd dlopening OSMesa all the time on engine init (and only when gl
is needed)... the amount of dirty pages went from 17208 to 8860.
that's a whopping drop of 8mb! 8mb saved! in fact just dlopening
osmesa and doing the other gl init stuff led to more anonymuse
mappings with dirty pages. 2 of them (2072k and 2076k) which baffled
me as that didn't seem like heap or efl's own data. these disappeared
along with libLLVM-5.0.so (3520k + 60k dirty pages). we stopped
linking/loading libedit (12k dirty), libglapi (20k dirty),
libLLVM-5.0 (3580k dirty), libncursesw (72k dirty),
libOSMesa.so (260k dirty), libtinfo (20k dirty). ... or at least
stopped until absolutely needed. total 17208k of dirty pages went down
to 8860.
my test case was just launching terminology (and doing nothing with it).
@fix memory bloating
Summary:
The default backend overrides this operation depending on the fill color
but the cairo backend dosen't hence cairo will always use bled mode while drwaing the vector.
Reviewers: jpeg
Subscribers: vtorri, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5724
so xine module plus 2 eina dbug threads didnt set up signal
blocking/masks correctly. xine use ssigprocmask not pthread_sigmask
and the other 2 didnt even bother at all. fix this so these threads
all block most of these commnly caught signals so these threads never
get them
This is very useful to specify precisely which kind of RGBA -> Alpha
conversion you want. If all you wanted was the alpha layer to use as a
mask, set this flag to true.
@feature
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>
This small patch just checks that we have a valid surface and bo that
we can pass to gbm_surface_release_buffer. If they are not valid, this
causes a hard crash.
NB: This does not actually Fix the ticket issue....
ref T6483
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When a widget inherits layout in tries to set theme in group_add or in
constructor. When another widget inherits the previous widget, it sets
layout again with new klass name. This sets klass in the widget and
sets layout in super class, so that it can set layout only once.
Test Plan: Run efl_ui_widget related elementary test.
Reviewers: jpeg, cedric, woohyun, singh.amitesh
Differential Revision: https://phab.enlightenment.org/D5473
Small patch to allow specifying a different seat via XDG_SEAT env
variable. If no seat name is passed as ecore_evas options, then we
would always default to 'seat0'. As this may not be desirable in all
situations, allow for an override via XDG_SEAT env var.
ref T6455
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The same pointer is valid post recovery, and anything that used to
check this for NULL now checks that the window's display is NULL
which is handled in ecore_wl2 now.
If we want to share a gl context (we do) between multiple instances of
gl_drm, we need to make sure they all use the same gbm_device.
This resolves a blocker for multi-output on the gl_drm backend.
Multi-head is hitting corner cases where there are lots of locked buffers
and it looks like right now 5 is the magic number that makes the problem
go away.
Make it possible to set 5 or more (via env var) for testing, make a macro
for MAX_BUFFERS instead of just a number.
We no longer allocate 3 buffers at startup, we now allocate only as needed.
Trimming the queue will come later, as there are some situations where we
might need 3 buffers and later drop down to 2 (when on a hardware plane)
Most clients will only ever need 2 buffers, so this is a reasonable RAM
savings.
It does us no good to be able to allocate dmabuf capable memory if the
compositor can't handle it. This should fix failures on systems where
allocation is possible but the compositor doesn't advertise dmabuf.
This moves all the platform specific buffer allocation into ecore_wl2
instead of the engine.
Note that this makes an internal struct available in the header. This
will be removed shortly.
Currently the buffer code looks up the alpha stats from the surface code.
This won't be possible when we move the buffer code into a library, so
prepare for it now.
Vincent Torri
Carsten Haitzler
Mike Blumenkrantz
subhransu mohanty
Marcel Hollerbach
Marcel Hollerbach
Jean-Philippe Andre
Ross Vandegrift
Chris Michael
Pawel Aksiutowicz
Sungtaek Hong
Derek Foreman