_e_menu_realize was trying to swallow the menu->container_object into
the menu->bg_object, but the menu->bg_object was being created on the
compositor canvas, and the container object was being created on the
With recent EFL changes, this causes an abort inside Evas.
To fix this, set the menu->evas to be the Evas from the e_comp->elm_win.
Signed-off-by: Chris Michael <firstname.lastname@example.org>
man xset => If the `threshold' parameter is provided and 0, the
`acceleration' parameter will be used in the exponent of a more
natural and continuous formula, giving precise control for slow motion
but big reach for fast motion, and a progressive transition for motions
in between. Recommended `acceleration' value in this case is 3/2 to 3,
but not limited to that range.
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
since ICCCM requires that clients be unmapped while iconified, it's necessary
for the compositor to perform one last render prior to the unmap in order to
ensure that mirror objects will still appear as expected. this render must use
the pixmap buffer data in order to avoid timing issues due to async/deferred
rendering, and it is only necessary for the case of clients rendering with a
E_Client->comp_data is null after a client has been deleted, so
attempting to handle events which require the dereferencing of this
pointer after a client has been deleted will result in a crash
these events should be rejected after delete regardless, since at this
time the compositor has stopped handling events for the client
i got a crash here and the bt was broken and i couldnt check if
_e_comp_x_client_data_get() returned null, but it's the only thing
that would make sense, so protect against this to avoid a crash. as
this was a one-off, i can't find out more,
the current spec does not directly require any behavior from clients
when a systray host, leading to an issue where clients do not re-register
their items when a new host appears
when using an in-process systray watcher, as the current implementation does,
the best choice for maintaining consistency for systray items across restarts
is to cache them according to the current dbus session. the process of setting
up the item will validate it on subsequent restarts, and changes to the session
will clear the cache
return value is small enough, so there is no risk in casting from unsigned int to signed int.
Reviewers: devilhorns, raster, cedric, zmike
Subscribers: seoz, sachin.dev
Differential Revision: https://phab.enlightenment.org/D3179
in the case where a shaped window with many rects exists, there is a high
probability of the damage rect count being huge, leading to massive blocking for
each frame as the compositor attempts to fetch all of these rects from the xserver.
instead, the compositor can shortcut this by forcing a full-window damage any time
the rect count is sufficiently high, trading a blocking socket operation for some
amount of (potential) overdraw.
testing in affected scenarios has shown huge improvements: where previously the entire
compositor would lock up, things work as expected now
see https://bugzilla.mozilla.org/show_bug.cgi?id=1214746 for a sample case
so a bit of a config wipe had my comp config reset (some dev
shenanigans) and i got to see what current e "out of box" config is -
and it was horrid for menus. visibilitiy effect was broken. vertial.
default was none - always. forever. like empty. so go back to that. in
fact why do this visibility effect? that was the point of having a
different shadow in the theme - each has its own look + effect. this
makes things far more complex...