So ok. haha. Amusing. But this is inappropriate. 1. It's not an INTENDED effect in theme so unless the theme ius doing it - it shouldn't happen. 2. There are places to do this and it's NOT inside an engine. There are high level filter and other mechanisms. 3. Actually this shouldn't be even done client-side. It should be done compositor-side when moving a window around. Knowing velocity vector etc. is useful to a client so the protocol can stay but doing the animation client-side is "wrong". Some windows wobble and others do not based on toolkit? really? sure we have to live with the CSD difference but this? The compositor can do this JUYST fine. leave it to compositor... OR do this properly with filters client-side. e.g. a 2d displacement map with evas filters would do the job as long as it interpolates. If you want a way of forcing ALL objects in the canvas to redirect to an intermediate buffer then do it up there at the canvas level. It then works in GL and software, as opposed to only GL. Also.... this is now causing issues for users: <memeka> hi, from https://git.enlightenment.org/core/efl.git/commit/?id=fb76fe55a52ac212b6870f1d74470a79ea5c5246 i run EFL_WAYLAND_DISABLE_WWW=1 terminology -> but it crashes in wayland_egl/www.c in the setup_shaders function .... HELP? so the fun was fune until we do a release (now) and until this causes problems for users. Back to tried and tested code. If you want to do this... do it right at the portable layers above. ... Revert "wayland-egl: Fix use after free" Revert "wayland_egl: Fix redirect to texture" Revert "evas-wayland-egl: Add www protocol handling to wayland-egl engine" Revert "gl_common: Add API for redirecting render to texture" This reverts commit |
||
---|---|---|
.. | ||
ecore/system | ||
ecore_buffer | ||
ecore_evas/engines | ||
ecore_imf | ||
eeze/sensor | ||
eina/mp | ||
elementary | ||
emotion | ||
ethumb/emotion | ||
evas |