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
Thanks @raster for pointing this out: title bar and menu bar
were resized down to 1 pixel high rather than 0. This meant that
all CSD windows would see a 1-pixel line between the title bar
and the app content, while SSD windows would see a 2-pixel line.
Also clip out the icon, this makes a 1x1 pixel disappear from the
top-left corner.
This series changes evas focus events, always providing
Efl.Input.Focus, making their usage way more straightforward.
Patches by Guilherme Iscaro <iscaro@profusion.mobi>
Differential Revision: https://phab.enlightenment.org/D4412
Rewrite and greatly improve error checking, allow multiple commands to
be given in series, etc.
This also leverages on Efl.Io.Queue to buffer data for us, then all we
need to do is peek at its contents, when there is a full message we
use and then ask the queue to discard it.
The CLST processing was also rewritten to not allocate memory. Since
memory may be unaligned we still iterate over the buffer and memcpy()
to an integer to avoid alignment errors.
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.
Summary:
After changes done on commit 9f8e2e0d9c
it was possible to have multiple devices with the same
id added throught the function
_ecore_evas_wl_common_cb_global_added().
To avoid such issue, let's check if the device was already
created first.
Reviewers: iscaro
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4428
Carsten Haitzler
Gustavo Sverzut Barbieri
Andrii Kroitor
Vitalii Vorobiov
Hermet Park
Jaehwan Kim
Jean-Philippe Andre
Bruno Dilly
Guilherme Iscaro
Jean Guyomarc'h
Stefan Schmidt