if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary: When an initial client application was shown and we tried to
resize it, the resize would jump by the amount of framespace. This was
because the xdg_surface@configure event would be sending window
geometry as the width/height params in the event. We need to account
for that in the callback of window configure and adjust size
accordingly.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary; This fixes an issue where maximizing efl/elm apps in Weston
and in Enlightenment would cause extra space to be left around the
window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
in the case of operations which change framespace, rejecting resizes
at this point will cause the canvas to fail at resizing and result in a
partially-rendered canvas; the real canvas geometry must be calculated by
running the entire function in order to determine whether the resize is valid
fixes toggling borderless state of windows
when running in a wayland compositor, the ideal mode of operation is to
only prepare/send frames when the compositor has finished with the previous
frame
to achieve this, manual rendering can be toggled upon creating and completing
a frame callback, ensuring that a canvas never has multiple pending buffers at
any given time
fix T2784
when a render occurs, frame callbacks must be managed in order to ensure
successful rendering for future frames. the best place to do this is in the
engine here, since this is the lowest-level place which has access to both
the wl_surface as well as the evas rendering state
ref T2784
Summary: If we have already resized this ecore_evas to be what we
want, then there is no point in running the below resize code as we
should already be at the requested size. Add a test at the beginning
to see if we have already set these values
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
for framespace
Summary: As we have already adjusted for framespace in various code
leading up to a configure callback, don't adjust for it here. This
fixes an issue where xdg surface window geometry would get incorrect
values which were including framespace. The values of the
xdg_surface_set_window_geometry should be Just the geometry of the
visible window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
processing updates
Summary: When processing render updates, we should be checking if the
Ecore_Evas "should be visible" property is set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we no longer need the wdata here (see previous commit), we
can remove the usage of this variable
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This function should really not be called here as it triggers
an xdg_surface_set_window_geometry call which (in turn) should only be
getting called when the window geometry (meaning visible region)
itself has changed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we end up calling ecore_evas_wl_common_resize anyway,
there is no need for all these size calculations in the configure
callback. The resize function will deal with this anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: If we are calling ecore_evas_object_cursor_set with a NULL
object, then we need to inform the ecore_wayland window that we no
longer have a cursor surface.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
engine
Summary: Frame callbacks are now handled inside the engine itself and
are thus not needed here anymore
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
configure event handler
Summary: This patch ports the fix for windows without a min/max size
being set over to the configure event handler (which was also not
taking into account the fact that Some windows may Not have a min/max
property set on them.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes an issue for windows which do not set a min or max
size in the properties. This was discovered when running Enlightenment
in a Wayland-Only scenario, and trying to bring up the settings panel
which would cause an endless loop in calculating the proper window
size due to min/max not being set.
@fix
NB: Thanks to Mike for the help in tracing this ! :)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
xdg_shell protocol supports minimizing surfaces. When elm apps request
iconification, they will call ecore_evas_iconified_set which in turn
will make use of the newly added ecore_wl_window_iconified_set function.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Recent expedite changes have uncovered an issue where the ecore_evas
(under wayland) was not supporting async rendering correctly. This
fixes the issue so we can run expedite with -y and get redraws again.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
ecore_evas_cursor_object_set
NB: Previously, if we mad calls to ecore_evas_cursor_object_set to update the
mouse cursor hotspot, the mouse cursor would be repositioned at 0,0 on
the canvas due to x & y being set to 0,0. We fix that here by fetching
the current mouse position Regardless if we are changing the object or
not (ie: perhaps we are just updating the hotspot and not the object)
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
@fix: As it turns out, we cannot just blindly set the regions here
during resize. Elementary apps will set the opaque region to account
for any edj frames, and having the region_set calls Here was
causing issues....
Signed-off-by: Chris Michael <cp.michael@samsung.com>
and update input & opaque regions after resizing.
@bugfix: We do not need to call ecore_wl_window_damage & commit here.
The damages are already handled in the evas engine for both shm & egl.
Those damages are sent to the compositor Already from the evas engine,
so we don't need to send the same damages twice. This reduces more
useless compositor redraws as we are not constantly sending damages &
calling commit twice for every frame.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this fixes a misbehavior with ecore evas object cursors when you set
one, the old one is deleted, but if the old is the same, the new one
you set gets deleted, rather than just updated.
@fix
Remove unused function and it's declaration. This function is not
being called from anywhere anymore, so it's no longer needed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Properly fix efl wayland elm window resize problem.
This adds support for min, max, step, aspect, and base size properties
when resizing a canvas under EFL Wayland.
This Also Properly fixes raster's report for EFL Wayland elm windows not
resizing properly. Previously, when resizing an elm window in wayland,
a portion of the window would draw outside the frame.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
outside the window).
Be sure that the EEs requested geometry gets updated in our
common_resize function After min/max have been taken into account.
Elm is using ecore_evas_request_geometry_get in it's resize_job code
(Why...I have no clue lol. Does not seem like a good thing to check).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This callback must be manually destroyed and removed on
ecore_evas_hide(), because it won't be delivered anymore after the
surface is destroyed. If the callback still exists, the engine will find
it and avoid doing a new redraw until it is finally called.
Maybe the correct thing to do is to keep this callback in the
Ecore_Wl_Window struct, and have some functions to set/unset it, so it
gets destroyed when the window is hidden. Or when the surface is
destroyed.
Fix phab T392.
Notice that it should reopen T359, as it wasn't really fixed, but a
rotation with resize was being used when a non-resized rotation was
requested. The cause of the "protruding surfaces" is likely the fact
that Elementary is setting the opaque regions manually, instead of
leaving it to Ecore_Evas. This must be fixed either inside Elementary
itself, or adding the "surface extents" (shadow/non-visible surface
parts) info to Ecore_Evas too.
This reduces code duplication for ecore_evas resize routines inside
wayland engines by using a common _ecore_evas_wl_common_resize
function as the resize code for both engines was the same anyway.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
These two APIs will save the title and class_name inside
Ecore_Wl_Window, so if they are called before the shell surface is
created, the stored names will be used later when the window is finally
shown (shell surface is created).
This way we are also hiding the shell surface from ecore_evas modules.
This is a configure event info, so put it in the right place. Some
places adding edges info were also removed, which means that they were
redundant.
Tested with <Meta> + middle click resize, and with window border resize,
on all the edges. Apparently, nothing breaks.
Previously, a "maximize" of an efl client would not actually resize to
the provided size as it would account for framespace width & height.
This fixes that so now "maximize" is Actually maximized.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
needed.
NB: Currently, this will only work for fullscreen or maximized states
as other ones like sticky, withdrawn, iconic, etc, etc are not
supported via wayland protocol yet.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
duplicated code.
Resize the frame object before we update the window saved size.
Remove (again) call to _ecore_evas_wayland_resize and set the resize
edge of the window.
NB: The call to _ecore_evas_wayland_resize ends up sending duplicate
configure events here, hence whey it is removed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
NB: Not sure how/why this was here, but it's entirely Not needed and
leads to duplicate calls of wl_shell_surface_resize.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
- In common_render_updates_process, calls to window_damage will
Accumulate the damage, so add a call After to push damages.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
It is needed to set the engine internal borderless property.
Also update the border (frame) object, showing/hiding it as needed, and
updating the framespace size when the frame object is handled by the
engine.
If this Ecore_Evas already has a mouse inside it, there's no need to
send an additional mouse in event.
Additionally, always send a mouse_move event before a mouse_down, so the
Evas pointer position can be updated properly before the mouse down.
Now the opaque and input regions are updated on ecore_wl_window_resize,
there's no need to call ecore_wl_window_buffer_attach() for this
anymore.
The checks on alpha and transparent flags were also fixed.
ecore_wl_window_update_size() is now called by ecore_wl_window_resize(),
reducing duplicated code.
Since we don't have a changed state callback on Wayland, just call the
changed_state callback of Ecore_Evas from the configure callback.
There's no need to add the Ecore_Job that will send the event later.
This makes the code cleaner, simpler, and will call the callback when
the configure event is received, which is a good place to check for the
changes.
In the window_configure callback, reduce duplicated/not needed code.
Account for rotation when getting new size during common_rotation_set.
Reduce duplicated code in ecore_evas_wl_resize function and just call
the _common_resize function (as that already has most of this code).
Fix issue of Segfault on elm app closing:
- During hide we need to call evas_sync to make sure the async
render has flushed out everything that is pending.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Instead of moving the objects by adding the framespace offset to them,
use this offset when rendering them. This way there's no change in the
object's geometry/position, it works correctly with map, and will be
automatically updated in case that the framespace values change (for
instance if one sets a window to borderless).
There are 2 main places where changes were needed:
- output redraws, when they come from an object being changed, must be
add the framespace offset to their damaged area;
- checks to see if the object is inside a given rendering area, must
also add this offset, since the object is actually being rendered on
a different position;
Add 4 rectangles to be used as border of the window, instead of a single
rectangle under the framespace. This allows to move the frame object to
the top layer, instead of staying on the lowest layer. With the frame
over the other objects, there's no need of framespace clipper object,
which causes several bugs.
The real canvas size contains enough space for rendering the frame, but
ecore_evas_geometry_get() should be consistent accross all the engines
and report only the client area.
When creating windows directly with Ecore_Evas, instead of using
Elementary, a default smart object is provided for the frame (client
side window decorations).
Now this smart object inherits from the clipped smart object, which
means that all its member objects will be clipped to its main clipper,
being skipped when the framespace clipper checks for objects without a
clipper.
Fix a ticket, which I don't remember the number because trac doesn't
work.
This will update the edges info inside the Evas_Engine_Info, and make it
correctly resize to the top/left if needed.
Also call ecore_wl_window_buffer_attach() on the egl engine, since it's
needed after the ecore_wl_window_update_size().
This will force the window to correctly update its size when the event
is received by the compositor, rather than just after an
ecore_evas_resize().
It fixes the window resizing of non-elementary applications, since
the elementary window already deals with such resize by calling
ecore_evas_resize.
This will allow it to report to Ecore_Evas that the window has changed
its state. Elementary uses this to update its maximized/fullscreen/other
window states internal information.
The code that uses this callback is also added to Ecore_Evas.
SVN revision: 83625
This avoids blocking in eglSwapBuffers and has the side effect of
avoiding doing unnecessary work - painting where a frame won't be
presented.
We do this by using the event that the wayland compositor will send us
to tell us that the frame has been presented. Due to the fact that
evas_render_updates() could do no work and not cause a eglSwapBuffers we
must always have a frame callback listener setup.
Original patch by: Rob Bradford <rob@linux.intel.com>
(I just adjusted the patch to the single efl tree)
SVN revision: 83387
Implementing support for loadables modules. It makes the engines been
loaded when they are needed. It not breakes the api, so each engine
still has its own api.
The implementation basically is:
* Functions that creates Ecore_Evas, for example
ecore_evas_software_x11_new, request to load its module and then get
the module's function to create the Ecore_Evas.
* The other functions such as \(.*\)_window_get from the Ecore_Evas
its interface and then call the appropriate method.
* As there is no unified interface to communicate with the engines
(not break api problem), all interfaces were declared in
ecore_evas_private.h
* Now the data necessary for each module is not declared in the
Ecore_Evas_Engine structure, instead of this, the struct has a void
pointer that is used by the modules.
* In this first moment engines as software_x11 and gl_x11 were put
together in the same module, but obviously exporting all the things
necessary.
SVN revision: 80280