This patch adds a new API function which will be called from
Ecore_Evas to return the screen dpi
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Support in case that If the expand mode is set to false
and the item is added using the item_append API.
Checking focus, entry visible is not needed to change mode in shrink when box resized.
If the view type is shrink when the MBE is in focus and the box is resized, it should be in shrink mode.
Test Plan:
elementary_test
MBE sample
Reviewers: woohyun, Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4429
As Andy reported, the main menu geometry is not correct after
my recent changes, as the application contents slide underneath
the menu bar. In fact the menu bar is just floating above
everything else.
So I've tried to move the menu to the framespace (as it should
belong to the frame), but the sizing algos for both the window
and the menu make some assumptions that render this task quite
difficult. Eventually I would like to be able to swallow the
menu somewhere else inside the border... but not right now.
x11 updates trying to update x properties from image data when icon is
not an image is causing lots of error spam. fix this to check type
first before getting data.
the ecore time based animator that ticked away used select for
timeouts to listen to either a timeout OR the control fd that would
tell it to tick or not tick. my profiles show this as consuming 1.03%
of my profile sample time - just the select call in the time based
animator. this adds the option of epoll + timerfd + having kernel
repeat the timer fd interval (since epoll timeouts at best can do 1ms
resolution). my profiling shows this to use 0.62% of profile time vs
1.03% for select, so it's a tiny win. this only compiles if epoll and
timerfd support have already been detected at compile time. it also
runtime falls back to select if epoll and timerfd setup fail.
@optimize
remove some extra looping and if checkign that is taken care of
already and just is pointless extra checks in the code creating
overhead. tiny amounts, but the amount of meaty speedups lef it
running low, so profiling, reading, working and repeating.
@optimize
evas_object_clip_recalc was already called ... multiple times in
pending and phase1 on all objects, so there is no value in calling it
again and again in later evbas render phases when it's already been
done.
this and moving this to a real func sees evas_object_clip_recalc usage
in perf drop from 1.8% to 1.4% or so of total perf sample time. tiny
win, but we're at the point where i can't find big meaty wins, so i'm
looking for a string of small wins to add up.
@optimize
evas_object_clip_recalc is big. it's fat. it shouldnt be inline. so
make it a real function. being inline just hurts performance by making
our code bigger, hurting l1 instruction prefetch and cache
performance. this function isn't small. it's huge and should not be
inline basically because of that reason.
also throw in some likely/unlikely hints etc.
@optimize
part of rendering is figuring if obj is inside current geometry.
before we had to actuall poke around inside the object. this moves the
geometry into the active object array so the data is fecthed fast and
already there for filtering as this is the most likely thing to filter
out an object.
unfortunately this seems to have some bugsd and i'm baffled why, so
leave it there and ifdefed out for now for suture hunting.
in much of phase1 we already know the evas object protected data ptr,
so dont scope data get it or even pass the eo obj id around as we can
get it from obj->object
_evas_render_is_relevant() needs the obj protected data, so it gets
scrop data, but the only place it is called already has this pointer,
so avoid an extra lookup.
@optimize
evas render in phase1 in order to generate update rects, active,
render etc. object arrays has to walk every object in our tree. this
is a waste of time if we already have walked objects in a previous
frame if they havent changed, so cache this data in render cache in
smart objects to avoid re-walking and now just dumbly "memcpy" these
cached arrays into the master array. i have seen cpu usage by e drop
like about 15% in the sencarios i'm looking at "enlightenment
compositor with some window updating animation all the time, but most
other stuff being static).
@optimize
these objects don't actually produce - or should produce update
regions etc. etc. as the objects that are clipped should produce those.
they are not active objects. so skip them very early after just
ensuring they are in delete objects if needed.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
Since all other efl.io objects are low-level, the recommended approach
is to use an efl.io.copier. However when dealing with in-memory,
bi-directional comms like talking to a socket, we always end with 2
queues, 2 copiers and the annoying setup that is being replicated in
ecore_ipc, efl_debug and so on.
This class is the base to make it simpler. Other classes such as
Efl.Net.Socket.Simple, Efl.Net.Dialer.Simple and Efl.Net.Server.Simple
will use it to provide simpler code to users.
I guess we can call EFL+EO Java now?
The may_block parameter is useful to force a flush without blocking on
read/write, sometimes particularly useful if ignore_line_delimiter is
true, then you get the data events without blocking -- as if a server
sending some content misses a trailing line delimiter, you do not want
to block on recv() but still want to flush data to user.
The ignore_line_delimiter parameter is useful if we're going to close
the copier and want to flush pending data which may exist due missing
trailing terminator. The close method will also force that if
destination can take more data.
I just realized that if a client is not referenced it would leak in
the 'ssl' server as we must del it.
However, if we del the SSL socket, we're going to close the underlying
TCP. But we're from the TCP "client,add" callback and this causes
issues since "closed" will be emitted, our close callback will
unparent the client, which lead to it being deleted.
The proper solution is to only monitor "closed" if the client is
accepted. Otherwise we just check if it was closed, if we're the
parent, etc...
Fixing this in all servers were painful, we could share since most
inherit from Efl.Net.Server.Fd. Then add the "client_announce"
protected method to do it, and document how it should work.
There was a bug that if the remote peer closed the connection, it
would trigger 'read' event, which would read 0 bytes, flagging as
EOS... but then marking as "can_read", which was wrong.
Just stop monitoring the events and fix that.
Because '\' is dir path for linux, but '/' is dir path for Window,
so better use specific function for getting file's name depending on specific
system
While using efl_io_queue + slice_get I found that we need to discard
data and the only way was to read to an actual buffer, kinda annoying.
Then introduce a discard method to do that.
My previous patches have broken E Wayland internal windows, as
the compositor wants to create Server-Side Decorations[1] but
based on some mysterious heuristics, E will decide to show or
not SSD. It seems the surface geometry, window geometry,
input region and maybe opaque region need to all match. There
was a pixel difference in the theme which broke everything,
also CSD shadows must be turned off in that case.
This also fixes inputs as for some reason a mismatching input
region vs window geometry would break pointer move/up/down in
those internal windows.
[1] I believe this is not a great idea and E should never draw
any server-side decorations in Wayland. Wayland was supposed
to mean only CSD, no more SSD.
as soon as we report 'can_read' or 'can_write', stop monitoring the
events until the user executes the operation, which will clear these
flags and we resume monitoring.
Summary:
when scroller page is enabled and key is pressed,
scroller will move in page by page.
Test Plan: elementary_test -> scroller
Reviewers: woohyun, cedric, jaehwan, raster, Hermet
Subscribers: akanad, jpeg
Differential Revision: https://phab.enlightenment.org/D4425
If we let the user know he can read or write, stop monitoring
otherwise fd handler will constanly report of data to read/write until
its actually done, which would clear the kernel flag.
Since we use "can_read" and "can_write" for that, toggle the callback
connection that manages the actual Ecore_Fd_Handler monitor.
instead of always delete and recreate it, modify if it already exists
and only delete if it's not needed anymore.
This results in epoll_ctl() to modify an existing handle, instead of
add one.
Each client (Ecore_Ipc_Client) is very similar to the handle
configured by ecore_ipc_server_connect() (the dialer), except we do
not have events such as "connected" and "error", as well as we don't
delete the socket as it's owned by the server, instead we close it.
The UNIX socket is configured similarly to ecore_con, setting the same
masks and mode for directories.
Instead of adding a job to create the socket and call bind(), do it
straight from the serve() method, this allows the caller to set
umask(), permissions and so on.
Document this behavior in the class, since we can't extend the
method's documentation.
Use the new Efl.Net.Dialer classes to implement
ecore_con_server_connect() scenario.
Note that since Windows still doesn't provide any equivalent to
Efl.Net.Dialer.Unix, we keep the legacy code for it.
Using the ecore_ipc_server_example with -m/--single-message, if we
deleted the client from the callback it would find a dead "cl".
As the "cl" handle is removed from svr->clients before it's deleted,
it's safe to check if we have that handle in the list before
proceeding.
The new efl_net code won't compose any path own its own, allowing the
user to connect to non-EFL systems.
However we need a way to use the same path Ecore_Con_Server does, so
we can reach it. Then export and use ecore_con_local_path_new() to do
exactly that.
This method will force a read-write cycle and returns if it's fully
done or not. It may be used to force data to be written before a
handle is deleted (when one can't wait for the data to be written
asynchronously).
E Wayland internal windows are a special beast. Somehow all their
events are intercepted by a special input_obj... but never get
propagated back to the elm_win.
Major side-effect: you get 2 window decorations. I believe there is
some dark magic inside E that tries to figure out when to show
a decoration and this conflicts with CSD.
But hey, it's late so I want to "fix" this and figure out the details
later.
elm_suite would crash when CK_FORK=no is set, because evas was
badly initializing or shutting down. Note that elm_suite still
crashes with CK_FORK=no but valgrind doesn't complain.
Func _eina_file_win32_first_file try to find the first file in directory
but if any file not found the file handler stay open, and func will
return error. But in this case while handle is open impossible to do
any actions. For example call eina_file_ls for empty folder, func will
return error and fold folder open. And if we try to remove this folder
Windows only mark it to delete, and remove it after the process is
complete.
Solution: close handler in error case.
if there is a event the callback counter should be incremented not
decremented. This should fix a few crashes i found in edje, since edje
did not knew that a element was deletion.
For standard windows, we want to create an elm_bg object if
the theme is a legacy one. Otherwise the default theme
doesn't require an extra object, just a rectangle.
This fixes compatibility with legacy themes (ie. every single
theme in existence beyond the default one, for now), by checking
where to swallow the menu widget. If a legacy theme is used,
the legacy swallow should be used, and it will all look correct.
Moving forward I hope to get rid of the internal edje object
entirely, except for compatibility reasons.
This simplifies the cases by adding a border edje on all
windows except fake (damn fake windows). Shadows and borders
are always disabled on such windows (but we could easily change
that in the future).
The idea is to not have resize object in a stack anymore,
but a couple of swallows in the frame and if the stack of
resize objects is wanted, then the user can still explicitely
create it.
This fixes invalid mouse cursor used when windows are
created.
Due to the changes in the border theme and the fact that
a border is now always created, the event region
"elm.resize.bl" contains the point (0,0) when the window
size itself is 1x1. As a consequence every EFL application
would permanently have a cursor like the resize bottom/left
handle.
This fixes that by properly checking whether the pointer is
inside an object based on the ins list, and not just the
object geometry.
@feature
See also: b735386a45
All windows, except for fake, inline & socket images,
should have a frame object to handle all the new APIs and
slots (background, content, indicator, etc...).
The theme will need to handle various modes:
- full CSD
- solid CSD without shadows
- server-side decoration (borderless without shadows)
- borderless with shadows
This means that the default theme must be used for windows,
so that the required edc parts exist. Apart from the standard
background, it is very unlikely that a theme will have changed
anything in win.edc, conformant.edc or border.edc.
This might prove a controversial move, but the alternative would
be to have increasingly complex code handling new themes with
a single edje object and older themes by swallowing tons of
components magically.
Eventually, the win edje object should also not be used anymore.
By default, windows should not have CSD enabled, except on Wayland.
This patch does not handle frame_obj with server-side decorations
yet.
Use Efl.Part for window to manipulate the background.
Two part names are used in EDC:
- elm.rect.background
- elm.swallow.background
For apps the part name is only "background".
To set a solid color background (alpha is ok):
efl_gfx_color_set(efl_part(win, "background"), r, g, b, a);
To set an image:
efl_file_set(efl_part(win, "background"), "image.jpg", NULL);
To set an object:
efl_content_set(efl_part(win, "background"), subobj);
The solid bg is invisible by default, will become visible and use
COPY render mode if a color is set. Standard window uses the
swallow part.
@feature
This is for client-side decorations on Xorg.
Mouse-based move and resize of the window now work fine, but
there are still a few glitches:
1- GL resize is awful (nothing much we can do)
2- Move/resize requests trigger a focus out event,
this in turn changes the style of the window from focussed to
unfocussed. This is thus different from what we see in Wayland
(no focus state change at all) and in usual X11 (focus changes,
but the frame keeps its focussed style).
To counteract this effect, we prevent the frame from changing
style on focus,out if we know we are moving or resizing. But
we don't know that if the compositor moves/resizes (eg. with
Alt key); The focus event happens too early, before the move
or resize events. At least in E.
The flag 'delete_me' is set when there are pending events to be
dispatched. Once these events are freed, they will check if the server
was pending delete and call ecore_ipc_server_del() again, thus we must
not return, otherwise data will be leaked.
Remove Elm_Url and use efl_net_dialer_http with an efl_io_copier to
fetch stuff.
The code was also slightly improved, particularly in elm_photocam
destruction be explicit and clear the grid before deleting... this
will ensure any pending preload are stopped before we remove the
backing memory.
this refactors _evas_render_phase1_object_process() into a bunch of
sub functions with leaner code, some LIKELY/UNLIKELY hints etc. etc.
in the hope that we have better l1 instruction cache use when
executing. this actually measureably helps and drops the overhead of
this func ANd all its sub functions from (in my tests in enlightenment
compositing while a video plays) from about 13.2% of all cpu usage by
e to 10%. that's about a 25% drop in cost for passing through phase 1
of evas render... and thats a good thing.
and it also makes the code nicer and more broken up.
@optimize
we are passing the same things into every phase 1 process func - the
same ptrs to the same arrays of objects... why eat up valuable
registers with this? collect into context struct and just pass a ptr
to that. this also makes the code easier to read and maintain too so
bonus all over. also a tiny win in performance but i'd say its "within
error margins" (go from 11.48% to 11.42% overhead).
this tests rendering of images with border scaling if they are small
(smaller than 256x256) to reduce geometry. part of testing a cpu
reduction effort in gl engine by pre-rendering primitive objects to
buffers.
Summary:
In case of thread creation failure, shutdown logic will be stuck.
To prevent stuck, set exit variables to make thread_shutdown working
even if init fails.
Also modify init logics to return init result to a caller.
Reviewers: jypark, woohyun, cedric, jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4411
Note (@jpeg):
I have modified the patch just a little bit.
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
The proper way to use the pixel_get callback and dirty flag
is to also specify which exact region has been updated
with data_update_add.
Unfortunately many apps and even GLView are relying on
invalid behaviour that forced full redraw of the image
even though data_update_add was never called.
This amends c1a080f5e4
There is no dirty flag equivalent in EO as there is no
pixel_get callback defined (yet). One problem is that the GL
API is not defined, and may prove hard to define for bindings...
Summary:
fix warnings while generating documents
- end of file while inside a group (eina_util.h)
- missing title after \defgroup
- ignoring title "Ecore_Con_Lib_Group" that does not match old title
Reviewers: Hermet
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4420
Summary:
"cursor,changed" smart callback should be called when only the main cusor's
position is changed. But, It was called when elm_layout_sizing_eval() is called
for elm_entry.
@fix
Test Plan: N/A
Reviewers: raster, cedric, woohyun, herdsman
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4419
Greatly reduce code complexity while providing better support, at
least according to @netstar efl_net_dialer_http works better than
traditional ecore_con_url on BSD.
The result of this API can only guarantee that the request has been forwared to the server,
In fact, there is no guarantee that the request can be processed by the server.
In order to use this API correctly, avoid the following conditions.
(The following situations will return a failure)
1. Calling a function in the absence of a touch(mouse) down event.
2. Calling the function twice more than once before the touch(mouse) up event.
3. Calling the function when the elm win already resizing or moving the window.
4. Calling the function using a combination of unsupported modes.
Right usage
1. touch(mouse) down event
2. efl_ui_win_move_resize_start only once using the supported mode combination.
3. touch(mouse) up event
If a touch(mouse) up event occurs after calling the function, it automatically ends the window move and resize operation.
Since there are some non-exclusive modes, you can use a combination of modes.(ELM_WIN_MOVE_RESIZE_MOVE is exclusive with others)
However, Some combination of mode is limited for technical reasons.
At present, only the following nine combinations are allowed.
For more information, see the Elm.Win.Move_Resize_Mode.
1. EFL_UI_WIN_MOVE_RESIZE_MOVE
2. EFL_UI_WIN_MOVE_RESIZE_TOP
3. EFL_UI_WIN_MOVE_RESIZE_BOTTOM
4. EFL_UI_WIN_MOVE_RESIZE_LEFT
5. EFL_UI_WIN_MOVE_RESIZE_RIGHT
6. EFL_UI_WIN_MOVE_RESIZE_TOP | EFL_UI_WIN_MOVE_RESIZE_LEFT
7. EFL_UI_WIN_MOVE_RESIZE_TOP | EFL_UI_WIN_MOVE_RESIZE_RIGHT
8. EFL_UI_WIN_MOVE_RESIZE_BOTTOM | EFL_UI_WIN_MOVE_RESIZE_LEFT
9. EFL_UI_WIN_MOVE_RESIZE_BOTTOM | EFL_UI_WIN_MOVE_RESIZE_RIGHT
Summary:
the new iterator represents the order from the elements of the original
iterator, elements where the filter callback return false will be
skipped.
The container of this iterator is the original iterator.
Test Plan: Just run `make check` there is a testcase
Reviewers: cedric, jpeg, raster, herdsman
Differential Revision: https://phab.enlightenment.org/D4417
During the replacement of the image with the new preloaded one,
the previous image is deleted but not removed from the list of
children of the icon (efl_ui_image), leading to Eo errors when
walking over the icon children.
@fix
Since connman is specific to linux, on other platforms just compile a
dummy "none" backend that will always report online and no other
details. This will be used in Windows, MacOS and other platforms that
still lack a proper backend.
The compile-time infrastructure also allows for networkmanager to be
added with ease, simply copy "efl_net*-none.c" or "efl_net*-connman.c"
to be a starting point and then add its specifics, adapting
configure.ac and Makefile_Ecore_Con.am
Compiling on rpi3 indicated that there are some unused variables in
the neon codepaths for several evas op functions. This patch just adds
EINA_UNUSED to the function parameters where needed.
NB: No functional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Compiling on rpi3 using neon indicates that 'alpha' and 'tmp'
variables are unused. Reading through the source confirms it, so
remove them.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previously we'd call this only when we absolutely needed to, so it made
sense to always attempt to free a buffer, including ones on scanout or
pending flip.
However, it's useful to have a way to release the "next" only, so we can
do that before starting a render to free up the buffer that's never going
to be scanned out.
The time to live hop limit should not be named loopback and have a type that
can actuall hold the number of hops. It already was always uint8 in the code.
Just fix the eo file.
windows is nasty and defines the value to be set or retrieved as
'char *', which triggers a warning when we use another kind of
pointer.
Partially addresses D4357.
windows is nasty and defines the payload to be sent or received as
'char *', which triggers a warning when we use another kind of
pointer.
Partially addresses D4357.
On Windows SOCKET is unsigned, thus will cause sign errors when
formatting with "%d" or comparing with signed values.
On UNIX it was quiet and easy to miss, thus a new #define can be used
to check for those. It will use 'unsigned long' as SOCKET, thus will
complain out loud and not even work correctly when using pointers on
64bits UNIX on mistakes -- which should improve the situation.
This helped to fix lots of missing conversions, all fixed.
This partially addresses D4357.
Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.
This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.
Usage:
Print the pointer:
(gdb) print $eo_resolve(obj)
$1 = (_Eo_Object *) 0x5555559bbe70
Use it directly (e.g. to print the class name):
(gdb) $eo_resolve(obj)->klass->desc.name
This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.
Note:
This feature is incomplete and only resolves IDs that are owned by the
main thread and in the main domain. This is not a big issue at the
moment, because almost all of our IDs are like that.
@feature