Summary:
Currently eolian abbreviates when only the last word of class name and
the first word of method name are same, but this patch abbreviates
generated c name of function to remove all duplicated affix.
For example, "efl_io_closer_fd_closer_fd_set" will be "efl_io_closer_fd_set".
Reviewers: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4430
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This series adds support to multiseat on
Evas focus state getter, add seat information
on canvas focus in/out events, per-seat focus
and mouse input / output.
Patches by Guilherme Iscaro <iscaro@profusion.mobi>
Differential Revision: https://phab.enlightenment.org/D4406
@feature
Small patch to implement support for ecore_evas_screen_dpi get on the
drm canvas. This will be used in enlightenment (e_scale) to get the
screen dpi of the compositor canvas when we call e_scale_update.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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.
Jee-Yong Um
Artem Popov
Bruno Dilly
Guilherme Iscaro
Chris Michael
Vitalii Vorobiov
Felipe Magno de Almeida
Gustavo Sverzut Barbieri
Stefan Schmidt
Woochan Lee
Jean-Philippe Andre
Andy Williams
Carsten Haitzler