Page MenuHomePhabricator

ecore-cocoa window issue
Open, HighPublic


After some reworking in elm_win, I think I have discovered an issue in ecore-cocoa handling: there is no event emitted from non-user resizing of a window. For example, if a window is resized from 10x10 -> 100x100, the app does not receive an efl event once the window is resized. There is some code around ecore_evas_cocoa.m:108 which implies that this is intentional, but I think this is a mistake; there must be an event notifying that the window has been resized so that the render size can synchronize with the window size.

The following patch should work, but it fails because there is no event received after the window is resized:

diff --git a/src/modules/ecore_evas/engines/cocoa/ecore_evas_cocoa.c b/src/modules/ecore_evas/engines/cocoa/ecore_evas_cocoa.c
index e1c5a66670..3ed1b995eb 100644
--- a/src/modules/ecore_evas/engines/cocoa/ecore_evas_cocoa.c
+++ b/src/modules/ecore_evas/engines/cocoa/ecore_evas_cocoa.c
@@ -80,11 +80,13 @@ _ecore_evas_resize_common(Ecore_Evas *ee,
    if ((ee->w != w) || (ee->h != h))
+        if (resize_cocoa)
+          {
+             ecore_cocoa_window_resize((Ecore_Cocoa_Window *)ee->prop.window, w, h);
+             return;
+          }
         ee->w = w;
         ee->h = h;
-        if (resize_cocoa)
-          ecore_cocoa_window_resize((Ecore_Cocoa_Window *)ee->prop.window, w, h);
         if (ECORE_EVAS_PORTRAIT(ee))
              evas_output_size_set(ee->evas, ee->w, ee->h);
@@ -113,6 +115,7 @@ _ecore_evas_cocoa_event_window_resize(void *data EINA_UNUSED, int type EINA_UNUS
         return ECORE_CALLBACK_PASS_ON;
    DBG("%p", ee);
+   ee->draw_block = 0;
    /* Do the resize */
    _ecore_evas_resize_common(ee, e->w, e->h, EINA_FALSE);
@@ -550,6 +553,7 @@ ecore_evas_cocoa_new_internal(Ecore_Cocoa_Window *parent EINA_UNUSED, int x, int
    ee->req.y = ee->y;
    ee->req.w = ee->w;
    ee->req.h = ee->h;
+   ee->draw_block = 1;
    ee->prop.max.w = 32767;
    ee->prop.max.h = 32767;
bu5hm4n triaged this task as High priority.Jun 11 2018, 1:23 AM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:50 AM
zmike edited projects, added efl: display system; removed Restricted Project.Jun 11 2018, 9:13 AM

If someone in this ticket isn't interested in resolving this soon then the 1.21 milestone tag should be dropped...

netstar claimed this task.Jun 22 2018, 8:58 AM
netstar added a subscriber: jayji.

I'll take a look at it. No promises! I've some free time though.

I think probably there are more important issues for the 1.21 release, let's table it for now.

Hi @netstar if you're not succeeding I will look - this should really get fixed for 1.21

Hey that sounds good :)

ping me if you need any help

I actually can't replicate this here - is there a small code snippet that I can use?

zmike added a comment.Jul 3 2018, 8:10 AM

It's a race condition based on a timing issue. It's entirely possible that there is no visible sign of this, which is why I removed it from the 1.21 milestone.

This would manifest mostly in the cases where an application resized itself or if the system decided to resize a window without user input for some reason.

Ah I misunderstood sorry.
I had thought it was something else from the description.
If it's not visible then I agree it's not a 1.21 problem.

netstar reassigned this task from netstar to bu5hm4n.Mar 21 2020, 4:28 AM

Marcel, I've no longer access to a macOS machine. If someone would send me one I'd gladly look into any of these issues. I'm reassigning to @bu5hm4n as he is the last person I know who did any macOS-specific work...

Every time they release a new OS lots breaks. Maybe it'd be best to tackle all these when 11 is public. There's all sorts of issues with windows and scaling need addressing. Is it worth spending time now to fix things with no idea what next is going to break in the forthcoming macOS 11 this year?