Small patch to add a handler so we can listen for when the surface
configure event is complete and can then go ahead and attach buffers
to the surface. This allows rage <filename> to work again in Weston :)
NB: This does allow rage <filename> to work under Weston now, but
still fails under Enlightenment for some reason :(
ref T5090
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to create and raise a new event letting ecore_evas know
when the window has been configured. With the addition of xdg_shell v6
support, we cannot commit a surface with an existing buffer until the
surface has been configured. This patch allows us to raise an event to
ecore_evas when the surface has been configured, so we can then attach
a buffer to it.
ref T5090
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch to compare if the hidden flag being passed in is the same
as the one stored in Outbuf. With the addition of xdg_shell v6
support, we cannot commit a surface with an existing buffer until the
surface has been configured. In order to facilitate this, we will use
the 'hidden' flag so that any surface_post does not actually attach a
buffer unless configure has already been handled on the surface.
ref T5090
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Now you can't use the same syntax as you would for a method to
implement a property as whole, instead you need to specify the
getter and/or setter explicitly. This is to allow parent classes
to expand their properties without altering behavior of the child
classes.
This reverts commit 5ae6e1db2f.
On Windows, system() does not execute file if the argument of system()
begins with double quotation marks.
(e.g. system("\"C:\efl\lib/edje/utils/v-1.18/epp.exe\" ...");)
To resolve this issue on Windows, it has been fixed to have the argument
of system() not begin with double quotation marks.
(i.e. Do not use double quotation marks for epp.exe path in system().)
Double quotation marks convert macros to a single macro string and only
the first macro becomes valid.
So double quotation marks are not used for macros.
As we cannot rely on window->display->serial to be accurate (it is
only set when there is input going on), we should be getting the
'serial' values here directly from a wayland function call.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
With the change to xdg_shell v6, we need to wait for any pending
configure to be handled before we can render. This patch addresses
that issue and makes Elementary_Test work again under Weston :)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
With the change to xdg_shell v6 we need to indicate that a window has
a pending configure event, and not show the window if a configure is
pending. In order to handle this, we add a flag to the window
structure and can check it inside ecore_evas.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When we get a configure event, we should be using the current display
serial to set as the window configure serial value. Previous code
would always end up setting the window configure_serial to 0 as
win->display->serial was not getting updated.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so here's the ugly problem. libproxy. yes. we've discussed memory
usage (e.g. it may have to execute javascript and pull in lots of deps
etc.) but we dlopene'd on the fly. ok... but this didn't solve another
issue i hit:
libproxy was causing enlightenment to abort(). some internal bit of
libproxy was raising a c++ exception. this wasn't caught. this causes
an abort(). takes down your entire desktop. FANTASTIC. this is bad. i
wouldnt' expect a library we depend on to be THIS anti-social but
libproxy seemingly is. it SHOULd catch its error sand just propagate
back to us so we can handle gracefully.
there reall is no way around this - isolate libproxy. it's even worse
that libproxy can load arbitrary modules that come from anywhere sho
who knows what issues this can cause. isolation is the best solution i
can think of.
so this makes an elf+net_proxy_helper we spawn the first time we need
a proxy lookup. we re-use that binary again and again until it exits
(it should exit after 10 seconds of being idle with no requests coming
in/pending). it'll respawn again later if needed. this involves now
the efl net threads having to marshall back to mainloop to do the
spawn and to write to the proxy process (reading is done by async exe
data events and the data is passed down a thread queue to the waitng
efl net thread). if the exe dies with pending requests unanswered then
it's respawned again and the req's are re-sent to it... just in case.
it has a limit on how often it'll respawn quickly.
this seems to work in my limited testing. this ALSO now isolates
memory usage of libproxy to another slave process AND this process
will die taking its memory with it once it's been idle for long
enough. that;s also another good solution to keeping libproxy impact
at bay.
Coverity reports this as in incorrect expression because it was
checking cache_entry width <= 0 twice. Fairly safe to assume that the
proper check should be width || height.
Fix CID1368336
Signed-off-by: Chris Michael <cp.michael@samsung.com>
so thelatest rpi kernels available e.g. in raspbian contain no fixes
for this yet so thatmeans basically ALL users would be affected, so
best to have a small workaround in ecore_drm2 to try the page flip a
few times until it works. this actually works. i try a usleep for 100
then try again. up to 500 times max then give up. actual numbers show
that betwee 1 to about 60 tries gets the flip to happen when these
glitches happen. log an error when this happens so we know it's
happening and a workaround is kicking in.
technically this would be much nicer if swapping had a dedicated
thread that could stall in this case and keep trying, but the odd
times it happens (seems to happen on average maybe once every 30
seconds) it wouldnt stall the mainloop or rendering and JUSt stall a
dedicated swapper thread. this requires a lot mor work to implement
though and we'd have to then ensure swaps ARe async with the swap
result coming back as an event etc... so a lot more work.
this at least makes rendering on the rpi stable and i can dig into
other issues like libproxy throws exceptions and causes a whole
process abort() as a result, or the latest mesa pkgs have totally
broken partial gl rnedering with all non-rendered areas being black
(it used to work though... until i updated).
@fix