i found e spinning at 100% just with 1 windows in wayland... open 2
terminology wins and move mouse form one to the other... 100% cpu. e
was moving seemingly a cursor client window? to the same coord again
and again as it was hidden...
this fixes that. no more spinning cpu
Under some circumstances we can defer frame callbacks forever for clients
that are only visible on desk mirrors.
I'm not certain those circumstances should actually occur (Ref T5678) but
at least for now this is a trivial and harmless workaround.
Fix T5654
it seems like this is a good place to try, and this seems to resolve
some render updating issues on restart, such as with maximized chrome
windows
ref T5599
in the case where an object is being shown before it has been moved or
resized, a move operation will trigger a series of callbacks which force the
compositor to attempt an illegal operation (recursive show before resize)
fix T5521
this is now handled by the event grabber. many callbacks on this
object are due to clip changes instead of genuine mouse movements,
meaning that processing events can lead to further resizes during a
render cycle
now i resize some windows and am in a white box of death each time...
this is really unfriendly... so downgrade to an err ad this is a
recoverable error.
in the case where this path was reached during x11 nocomp, the client's pixmap
refresh would be deferred until the end of nocomp, even when the refresh would
otherwise end the nocomp. instead, force the refresh immediately.
fix T4887
in the case where effects are disabled, no animation is started for iconify
operations, so this should fall through to the normal hide/show paths
ref T5444
This reverts commit cd3490f35c.
this breaks many windows by preventing deferred resizing from occurring.
a window which is unable to resize at the time of this call must be queued
for a deferred resize, otherwise it may never resize at all and thus will
never be rendered
test case: screenshot dialog
animating comp objects persist after the lifetime of their client, so
ensure that functions which are likely to be called after the client's free
will not attempt to access client struct members
we did cast to Evas_Native_Surface * but this just causes warnings due
to the input ptr being char * from memcup. as this will be aligned due
to allocation, we're ok, so use a void * cast instead
so on 1 intel laptop and my rpi i'm seeing 100% cpu usage in wayland
mode. it seems something is resizing to 0x0 and then causing a size
change which causes a property change which causes... another request
to 0x0 and repeat. dont set tyhe size changed flags if size actually
didnt change and this fixes that.
this adds core basic handling for window stacks where windows behave
correctly as a single unified stack something like what naviframe does
but out-of-window so you can including multiple processes. only on x11
right now as it's being supported/worked on.
as we dont plan to kepe naviframe in future, this is the way to go.
naviframe "pages" will be windows in a stack. the wm should do the
nice thing. in e this will be very nice. for now elsewhere we use
transient_for so a wm would treat this like a bunch of dialogs with a
single parent window. i guess in a desktop thats probably what you
might expect. e will be a little more "finesse" filled.
need to make ibar, tasks,m win menu and winlist (alt-tab) respect this
and only show the top member of a stack.
need to send messages to clients when they are "top" or "middle" or
"bottom" or "alone" in the stack or something so decorations can change.
should add soem new border signals in theme (for both SSD and CSD) to
make this look nice. will need some config additions for that and
ability for e comp to do the right thing
but this is a solid start
==13307== 96 bytes in 1 blocks are definitely lost in loss record 6,598 of 11,698
==13307== at 0x4C2DA60: calloc (vg_replace_malloc.c:711)
==13307== by 0xCECA287: eina_tiler_iterator_new (eina_tiler.c:1299)
==13307== by 0x46D13D: e_comp_object_render (e_comp_object.c:3966)
==13307== by 0x46DB42: e_comp_object_dirty (e_comp_object.c:3923)
==13307== by 0x46017D: _e_comp_client_update (e_comp.c:343)
==13307== by 0x46017D: _e_comp_cb_update (e_comp.c:400)
==13307== by 0xB34D4BA: _ecore_job_event_handler (ecore_job.c:98)
==13307== by 0xB34909C: _ecore_call_handler_cb (ecore_private.h:317)
==13307== by 0xB34909C: _ecore_event_call (ecore_events.c:518)
==13307== by 0xB350527: _ecore_main_loop_iterate_internal (ecore_main.c:2359)
==13307== by 0xB3508A6: ecore_main_loop_begin (ecore_main.c:1287)
==13307== by 0x43C88A: main (e_main.c:1093)
This commit brings 2 objects to the group "e/widgets/border/default/border", an
icon and a slider. If you click the icon the volume is muted.
The slider set the volume level.
Theme part added "e.swallow.volume_icon" and "e.swallow.volume"
@features
Otherwise the popup will be where you are not looking at.
This patch adds a new function to e_comp_object where you can pass the
zone where you want to place the e_comp_object on.
ref T4499
i noticed a crash on texture update with a previous garbage image data
ptr set before becoming a native suttface and so setting alpha would
cause a texture upload from a garbage pointer, so set native surface
then set alpha on or off so the data ptr is no longer used.
@fix
Mirrors can be rendered independently of what they're mirroring,
which (at least under wayland) can result in a situation where the
mirror is rendered before the parent sets up their image pointers
properly.
We give mirrors their own callback to prevent that from causing a
crash.
Under wayland evas will sometimes use the old one, I have no idea why.
Fixes a crash bug when mousing out of menus in a GTK app under wayland.
fix T3576
internal wayland windows are windows with ssd, meaning they can only receive
pointer events on the contents of the window and not the entire window including
decoration regions
ref T3819
Wayland argb state depends entirely on the attached buffer, so we
should use that for determining object argb state on wayland.
ref 6d397e313b
ref 60da58d8ad
This test has been pushed into e_comp_object_native_surface_set() and
will be done as appropriate.
Upcoming wayland DMAbuf buffers need native surfaces even if GL isn't
present.
This is supposed to be functionally equivalent, but is a little tricky to
prove.
The benefit of this is a simplification to the callers, which no longer
have to consider gl capabilities in the call, as that is now tested for
internally.
Until now it's been reasonable to consider these together as the
criteria have been similar. With the upcoming introduction of wayland
DMAbuf buffers, they diverge.
We don't need to test for GL in the wayland case because we don't
advertise GL capabilities to clients when we don't support it, so they
can't create GL buffers unless we can display them.
if csd exists in only one of (before || after) a maximize/fullscreen,
this provides info so that the right size can be used when restoring
geometry
...again
in the case where a mouse binding is active and a signal binding is triggered
by the same mouse-up event which also ends the mouse binding, the deferred
nature of edje emissions will result in the signal being received by the
corresponding callback some time after the mouse-up event has been handled by
the client and the mouse binding has ended
to accurately handle these cases, signal bindings triggered in the same event
loop in which a mouse binding has ended after a mouse-up must be rejected in
order to enforce the compositor's mouse grab
fix T3347
an agent object can be used when a client should be represented on the
canvas solely by its window geometry and not including any csd
this creates and manages a mutable object which maintains the same geom
as ec->x/y/w/h and can be operated upon to modify those values
in the case where a client is at 0,0 relative to a zone, changing the coords
in this case will result in the client moving out of the zone by the size of the
csd