[e-users] Question on E17 animated backgrounds
Greetings all. I've been working with a friend on an animated background. What we've done is take a project in The Gimp, and rendered a LARGE series of images, changing the transparency of one of the layers by a very small amount each time. When we make an animated background from this series of images ( 88 of them ), the effect is very nice ( we think so anyway ), but it uses a LOT of CPU - even if we spread the animation out over 1 minute. Apart from culling our number of images ( which we'd rather not do, as the image transitions become noticable when we do this ), is there any other approach we can use? In particular, is there any way of just using 2 images, and getting E to modify the transparency of one of them? Or is our only option to use a series of images, as we've done? Thanks :) Dan ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Question on E17 animated backgrounds
On Sun, 18 Jun 2006 16:31:56 +1000 Daniel Kasak [EMAIL PROTECTED] wrote: I've been working with a friend on an animated background. What we've done is take a project in The Gimp, and rendered a LARGE series of images, changing the transparency of one of the layers by a very small amount each time. When we make an animated background from this series of images ( 88 of them ), the effect is very nice ( we think so anyway ), but it uses a LOT of CPU - even if we spread the animation out over 1 minute. Apart from culling our number of images ( which we'd rather not do, as the image transitions become noticable when we do this ), is there any other approach we can use? In particular, is there any way of just using 2 images, and getting E to modify the transparency of one of them? Or is our only option to use a series of images, as we've done? I have experimented with such things myself. As far as I can tell, it's the size of the images that controls how much CPU is used when dealing with transparencies. Full screen transparencies will soak up heaps of CPU no matter what you do. signature.asc Description: PGP signature ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Question on E17 animated backgrounds
You can try switch CONTAINER to GL mode, if you have working OpenGL
(only Nvidia works good for me) and evas compiled with GL engine.
Try these patches, recompile e and use this command:
enlightenment_remote -engine-set CONTAINER GL then restart E17 and it
should render background in OpenGL, which is much more faster (10x for me).
Mirek
Daniel Kasak napsal(a):
Greetings all.
I've been working with a friend on an animated background. What we've
done is take a project in The Gimp, and rendered a LARGE series of
images, changing the transparency of one of the layers by a very small
amount each time.
When we make an animated background from this series of images ( 88 of
them ), the effect is very nice ( we think so anyway ), but it uses a
LOT of CPU - even if we spread the animation out over 1 minute.
Apart from culling our number of images ( which we'd rather not do, as
the image transitions become noticable when we do this ), is there any
other approach we can use? In particular, is there any way of just using
2 images, and getting E to modify the transparency of one of them? Or is
our only option to use a series of images, as we've done?
Thanks :)
Dan
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--- e_config.c 2006-05-13 05:04:35.0 +0200
+++ e_config_mod.h 2006-05-14 19:36:13.0 +0200
@@ -1382,11 +1382,7 @@
{
Evas_List *l = NULL;
l = evas_list_append(l, strdup(SOFTWARE));
-// DISABLE GL as an accessible engine - it does have problems, ESPECIALLY with
-// shaped windows (it can't do them), and multiple gl windows and shared
-// contexts, so for now just disable it. xrender is much more complete in
-// this regard.
-// l = evas_list_append(l, strdup(GL));
+ l = evas_list_append(l, strdup(GL));
l = evas_list_append(l, strdup(XRENDER));
return l;
}
--- e_ipc_handlers.h 2006-04-09 13:55:18.0 +0200
+++ e_ipc_handlers_mod.h 2006-05-14 19:33:27.0 +0200
@@ -6820,21 +6820,16 @@
//
#define HDL E_IPC_OP_DEFAULT_ENGINE_SET
#if (TYPE == E_REMOTE_OPTIONS)
- OP(-default-engine-set, 1, Set the default rendering engine to OPT1 (SOFTWARE or XRENDER), 0, HDL)
+ OP(-default-engine-set, 1, Set the default rendering engine to OPT1 (SOFTWARE, GL or XRENDER), 0, HDL)
#elif (TYPE == E_REMOTE_OUT)
REQ_INT_START(HDL)
int value = 0;
if (!strcmp(params[0], SOFTWARE)) value = E_EVAS_ENGINE_SOFTWARE_X11;
- else if (!strcmp(params[0], GL))
- {
- value = E_EVAS_ENGINE_GL_X11;
- printf(GL engine is disabled as default engine.\n);
- exit(-1);
- }
+ else if (!strcmp(params[0], GL)) value = E_EVAS_ENGINE_GL_X11;
else if (!strcmp(params[0], XRENDER)) value = E_EVAS_ENGINE_XRENDER_X11;
else
{
- printf(engine must be SOFTWARE or XRENDER\n);
+ printf(engine must be SOFTWARE, GL or XRENDER\n);
exit(-1);
}
REQ_INT_END(value, HDL);
@@ -6919,7 +6914,7 @@
//
#define HDL E_IPC_OP_ENGINE_SET
#if (TYPE == E_REMOTE_OPTIONS)
- OP(-engine-set, 2, Set the rendering engine for OPT1 to OPT2 (SOFTWARE or XRENDER), 0, HDL)
+ OP(-engine-set, 2, Set the rendering engine for OPT1 to OPT2 (SOFTWARE, GL or XRENDER), 0, HDL)
#elif (TYPE == E_REMOTE_OUT)
REQ_2INT_START(HDL)
int context = 0, engine = 0;
@@ -6939,16 +6934,11 @@
}
if (!strcmp(params[1], DEFAULT)) engine = E_EVAS_ENGINE_DEFAULT;
else if (!strcmp(params[1], SOFTWARE)) engine = E_EVAS_ENGINE_SOFTWARE_X11;
- else if (!strcmp(params[1], GL))
- {
- engine = E_EVAS_ENGINE_GL_X11;
- printf(GL engine is disabled as default engine.\n);
- exit(-1);
- }
+ else if (!strcmp(params[1], GL)) engine = E_EVAS_ENGINE_GL_X11;
else if (!strcmp(params[1], XRENDER)) engine = E_EVAS_ENGINE_XRENDER_X11;
else
{
- printf(engine must be DEFAULT, SOFTWARE or XRENDER\n);
+ printf(engine must be DEFAULT, SOFTWARE, GL or XRENDER\n);
exit(-1);
}
REQ_2INT_END(context, engine, HDL);
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e-wiki?
On 6/19/06, radar [EMAIL PROTECTED] wrote: are there any ongoing developments on the wiki question? a wiki for documentation. i found a thread from april 2005 on e-devl in the archive. http://get-e.org/ Its a controlled WIKI, if you would like to participate, prepare something (or propose mods) and ask for an account to edit the site. (#get-e, HandyAndE, CodeWarrior, or devilhorns) -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] exiting e16 doesn't close apps properly
On Sun, 18 Jun 2006 19:11:02 -0400 Dennis Nezic [EMAIL PROTECTED] babbled: I posted a while ago about the way e16 exits -- in particular, how other apps (like gvim) are affected by it... http://sourceforge.net/mailarchive/message.php?msg_id=16523608 Bram Moolenaar of gvim fame seems to disagree: On Sun, 18 Jun 2006 16:16:01 +0200, Bram Moolenaar [EMAIL PROTECTED] wrote: Dennis Nezic wrote: when i exit my wm (e16), since it doesn't (and shouldn't) close any other programs, gvim is stuck without an x server, and doesn't handle this loss gracefully. effectively, it's as if it was kill -9'ed ... and thus leaves temporary files behind, which i later have to labouriously clean up. can it not do something better like simply close down if no changes were made to the file (and close any temp files). and, i guess, leave the temp files behind if changes were made (as it currently does in all cases :\). Vim normally handles a shutdown of the window manager gracefully. There is a protocol for this and Vim implements it. This may result in the window manager not exiting when Vim has modified files. If you forcefully kill the window manager or the X server you will get a hanging gvim (and possibly other programs). That's your own fault then. If you shut down the window manager properly but Vim still hangs somehow, perhaps the window manager doesn't work properly. You could try another one. He seems to be making sense. ? no he's not. there is not shutdown protocol for a wm - it doesn't exist in x. read the icccm. there is a protocol a wm can use to request an application to delete its window (and often apps will take this as a hint and take their sweet time about it - sometimes pop up are you sure you want to exit? dialogs etc.) but there is no protocol to say go shut down and cleanup ASAP and don't ask 'are you sure?' etc.. if he is referring to a shutdown/save protocol in a SESSION MANAGER (using libICE etc. etc.) THEN sure - there is one. but not for window managers that don't pretend to be a session manager too. my reply to enlightenment-users still stands. an app can trap loss of x connection and still shut down gracefully (make it an expedited shutdown with no are you sure dialogs - simply save and clean up as fast as possible). e17 does just that itself as did e16. they both handle loss of an x display themselves gracefully. i bet you vim isn't setting its own handler for x io errors (which is the handler called in this case, the default in xlib just calls exit(), unless you set your own). fact is - gvim should also handle the case where you ctrl+alt +backspace to kill x - and clean up, if it can (which it can). the only case where gvim could not manage a cleanup on shutdown is on a kill -9 as a process is killed off with no choice in the matter. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
