Summary:
there is no need to set repeatedly input region even if it's already applied.
and this patch remove the code to clear tiler from client's unmapped case.
this fixes that tiler for input region is removed before applying it to comp object in case client is unmmaped yet.
Reviewers: devilhorns, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3076
Sometimes, trying to go to the parent directory wouldn’t work and end up showing some garbage. Unfortunately, the code ended up not NULL-ending the path, which made searching for the path separator buggy.
in some cases, it's possible for a client which expects to render on
the next frame to actually render on the frame after. in these cases,
the compositor must not clear the pixmap image until after the render
has occurred in order to avoid inaccuracies. for this reason, the best
place to flag a client for post-render work is at the time of the client's
render
ref T2762
ref D3120
fixes case where plugging an external monitor would cause the screen
to expand onto that display without the display being effectively usable
until after a restart
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
==24509== Invalid write of size 8
==24509== at 0x502D00: _e_elm_win_trap_del (e_win.c:39)
==24509== by 0x509BFC2: _elm_win_evas_object_smart_del (elm_win.c:1886)
==24509== by 0x91F4643: evas_obj_smart_del (in /usr/lib/libevas.so.1.15.99)
==24509== by 0x91F5B5C: evas_object_smart_del (evas_object_smart.c:1021)
==24509== by 0x91E9107: _evas_object_eo_base_destructor (evas_object_main.c:739)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x5086715: _elm_widget_eo_base_destructor (elm_widget.c:5744)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x4D5B1A: _e_obj_dialog_free (e_obj_dialog.c:125)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x4EDC54: _e_sys_logout_after (e_sys.c:750)
==24509== by 0x4ED7AC: _e_sys_action_do (e_sys.c:925)
==24509== by 0x4EE348: e_sys_action_raw_do (e_sys.c:311)
==24509== by 0x4EE43F: _e_sys_comp_done_cb (e_sys.c:66)
==24509== by 0x6097348: _edje_emit_cb (edje_program.c:1476)
==24509== by 0x6097348: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
==24509== Address 0x14fb1a28 is 1,176 bytes inside a block of size 1,352 free'd
==24509== at 0x4C2A65B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x502CED: _e_elm_win_trap_del (e_win.c:37)
==24509== by 0x509BFC2: _elm_win_evas_object_smart_del (elm_win.c:1886)
==24509== by 0x91F4643: evas_obj_smart_del (in /usr/lib/libevas.so.1.15.99)
==24509== by 0x91F5B5C: evas_object_smart_del (evas_object_smart.c:1021)
==24509== by 0x91E9107: _evas_object_eo_base_destructor (evas_object_main.c:739)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0x5086715: _elm_widget_eo_base_destructor (elm_widget.c:5744)
==24509== by 0xE54A8A3: eo_destructor (in /usr/lib/libeo.so.1.15.99)
==24509== by 0xE5443EC: _eo_del_internal (eo_private.h:221)
==24509== by 0xE5443EC: _eo_unref (eo_private.h:295)
==24509== by 0xE5443EC: _eo_do_end (eo.c:546)
==24509== by 0x4D5B1A: _e_obj_dialog_free (e_obj_dialog.c:125)
==24509== by 0x4D61FB: e_object_free (e_object.c:152)
==24509== by 0x4D61FB: e_object_unref (e_object.c:152)
==24509== by 0x4EDC54: _e_sys_logout_after (e_sys.c:750)
==24509== by 0x4ED7AC: _e_sys_action_do (e_sys.c:925)
==24509== by 0x4EE348: e_sys_action_raw_do (e_sys.c:311)
==24509== by 0x4EE43F: _e_sys_comp_done_cb (e_sys.c:66)
==24509== by 0x6097348: _edje_emit_cb (edje_program.c:1476)
==24509== by 0x6097348: _edje_emit_handle (edje_program.c:1405)
==24509== by 0x60924EE: _edje_message_queue_process (edje_message_queue.c:787)
==24509== by 0x60926A6: _edje_job (edje_message_queue.c:154)
==24509== by 0xCC5087A: _ecore_job_event_handler (ecore_job.c:121)
==24509== by 0xCC4B204: _ecore_call_handler_cb (ecore_private.h:390)
==24509== by 0xCC4B204: _ecore_event_call (ecore_events.c:565)
==24509== by 0xCC52AE7: _ecore_main_loop_iterate_internal (ecore_main.c:1927)
==24509== by 0xCC52CD6: ecore_main_loop_begin (ecore_main.c:983)
==24509== by 0x4383F4: main (e_main.c:1047)
if this isn't explicitly blocked by config options then allowing resizes
on the unmaximized axes is necessary in order to avoid accidentally
queuing a full unmaximize
according to ICCCM 4.1.4:
Only the client can effect a transition into or out of the Withdrawn state
withdrawn windows cannot be shown under any circumstances. the best that can
be done is to try mapping the window and hope it decides to appear.
to prevent any inadvertent showing of the window before it leaves the
withdrawn state, we play games with the E_Client->ignored flag in order
to skip client evals until we get notified that maybe we want to stop
skipping those evals
ref T2745