_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
e_comp->elm_win.
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 <cp.michael@samsung.com>
when applying new csd to a window which already has csd, the previous
csd must be removed in order to apply any new csd offsets in order to
avoid unwanted moving/resizing
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
ref T2784
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
native surface
fix T2788
the env var DBUS_SESSION_BUS_ADDRESS may not be set for all platforms
where enlightenment+dbus are usable, so it's necessary to get the dbus
id to ensure that this value exists and is properly tracked
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
ref f42c6aa187
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,
@fix
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
fix T2786
Summary:
return value is small enough, so there is no risk in casting from unsigned int to signed int.
CID: 1267211
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
e_config->backlight.idle_dim is actually an unsigned char in the
structure, so use a 0 & 1 for min & max
Signed-off-by: Chris Michael <cp.michael@samsung.com>
it seems that damages for popup windows in some applications,
namely blink-based browsers, are reported incorrectly, resulting
in sometimes having a blank window
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...
Chris Michael
Mike Blumenkrantz
Seunghun Lee
Thierry
Carsten Haitzler
Marcel Hollerbach
Amitesh Singh
Tomáš Čech
Tom Hacohen