Previously the output base name used to include extension, now
you don't need to specify an extension and it's determined from
the input file name instead.
Also, implementation boilerplate used to merge with .eo.c before,
which made no sense. Now it's merged with .c instead when it
exists or makes a new .c file when it doesn't.
In Enlightenment with internal window being WL window connected to the
X11 backend, you end up with the later requiring the former to tick, even
if the former do not have a proper animator source. To work around the
problem when there is one backend that is not providing support for
animator source, we do need to avoid switching on another window source
as they could be linked somehow and we can not know.
This make EFL_MAIN available and working with just Ecore. For simplicity
it is available with Efl_Core.h. Ideally it should also work with Efl_Net.h
alone and finally with an Efl_Ui.h.
T6262
We need at least version 2 for create_immed, so don't even bind the
global if it's useless to us.
This will also stop us from trying to use dmabuf (and getting killed by
the compositor) on older compositors that don't support the version we
need - we'll just use wl_shm instead when this pointer is NULL.
Keep track of visibility and ensure the cursor can never be
filled when hidden. This should finally end any issue with the
cursor and visibility with the new focus system. Didn't see this
previously until working on Edi's bottom panes which caused redraw
on resize of the widgets.
@fix
This is what the old shm code has been doing, and it's probably better
than what the dmabuf code was doing.
We currently allocate 3 buffers. The usual case has us swapping between
two of those buffers and saving that third buffer for emergencies - if
we ever need that third buffer it'll require a full redraw.
If we return the oldest available buffer the usual case requires a little
more damage but we should never hit the full redraw case, which can cause
a frame drop on slow hardware.
Now that we're dependent on create_immed there's no possibility of falling
back to non dmabuf allocation.
The only failing case we really need to handle is failing the first
allocation, which is currently broken and I'll be adding an advance test
for it shortly.
wl_shm and dmabuf only really need to differ in how they allocate a buffer,
but right now we've got them in separate files. This dramatically
reduces the complexity of the wl_shm code and shares much more
implementation with the dmabuf code.
This throws away at least one "optimization" wl_shm used - over-allocating
buffers so that window resizing doesn't always require a new buffer
allocation. If people feel that window resizing has become too slow now
this can be added to the dmabuf code to the benefit of both allocators.
Disabling dmabuf by env var still uses the old wl_shm implementation for
now, but soon that code will be removed entirely and the env var disable
will use this path.
as decided by unanimous vote, the community does not want builds to pause or
stop when various features are disabled. warnings for disabling features have
been left intact
ref V30
@feature
this is needed for devices that no longer produce aspi events for
these. otherwise good luck getting any event on lid open/close or on
pressing the power button. this also stops hiding switch events from
libinput and now you can get switch events to find lid or tablet mode
switching changes.
@fix
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
we cant go iterating the mainloop before the current point. if someone
set up handlers but hasnt configured the things those handles use yet
as they dont expect them to be used until the mainloop is started...
thenthings break. we cant change this assumption without breaking
things.