Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). Ok, trying to reply to the torrent of ideas from you ;-) No torrent of ideas, just simple basic things that I've already run across and thought might help for you to keep in mind. - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) - filter chaining: needs evaluation on good api to negotiate between filters, those that can be done within the matrix (ie: just add to transf matrix), do, others will require the intermediate buffer and will operate on it. So Rotate+Translate+Blur would generate Rotate+Translate in matrix, output a temporary buffer that blur would operate on. This may be suboptimal, but is very easy to work on. - rely on hw-acceleration (shaders and like): it's easy, it's almost everywhere and people are gaining market share by naively using it. We don't even allow users to use it. If you have or not such great hardware, you're unable to use it today. So why not expose this and let users use their hardware? Also, we can still support some of these in software (ie: matrix transf) easily, while others we can simple ignore.Most users (ie: E17) will try to keep with supported-everywhere, avoiding things that might depend on hardware. But others (ie: Rage) could try to use these fancy effects, since they know most of their users will have such hardware. Also, we could use Sure, and that's why things like 'native surfaces' or other methods for custom rendering would be useful - so that people can do those kinds of things if they wish. Gallium3D or even go with LLVM directly to get some kind of JIT and have software-only implementation that is highly optimized, without having to care much about it ourselves. All in all, this filter thing is all about exposing some of hardware acceleration without having to explicitly implement it in Evas (as it's done now for things like YUV-RGB conversion, Scale, Colorize, Fade, ...). Actually I was about to go with this individual implementation, like adding evas_object_rotate() and like, but raster and others convinced me that going with a generic filter implementation would be more extensible. Going with super-fast custom case for each of this will span a huge number of function implementations (ie: rotate solid-solid, rotate transp-solid, rotate transp+alpha-solid, ... all of these for C, MMX, SSE, SSE2, Altivec, 16bpp, ...), since this is non-sense for such things that are barely used, let's make it more generic and have the optimizations to be done elsewhere. Well, that sounds great! Looking forward to seeing this finally in evas. :) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
Hi Dave, * [13.04.08 03:37]: Hi, really a good module !! good work This version works well on my machine, also my xterm problem seem solved :) Thanks, good to hear :-). You should add an X-Enlightenment-ModuleType=system line to the module.desktop.in file to make the module appear in the right category on the module setting dialog. Is system the right category for you? Oh, thanks for the hint. I forgot this one. appearance is the more appropriate category, I think. New Revision is in the git repositories. In my opinion we can commit the patch for e as it's really simple and brake free, so to make testing easier. Yes, I think so, too. Anyone got CVS access and is willing to put the following patch in please? http://staff.get-e.org/?p=users/michael/e17-tiling.git/.git;a=blob_plain;f=desk.patch;hb=d1ff98e8d9de4cce37fa1643885413c0401b73e2 Also I think your module should replace the really too much simple layout internal module once it is stable enought. I think this one is to be used for something different (e17 on embedded devices), however let raster speak on this ;-). Now a feature request: the ability to set a border for the desktop that will not be covered by tiling, for example top 10px, left 100px... This is usefull if you have other staff than shelf around your desktop, like itask, trayer or module placed on the desktop ;) Ah, I see. I don't use anything like that so I didn't think about it before. Wouldn't the best solution be to integrate everything into shelves as it should be part of your windowmanager anyway? One way to fix that would be to let the module not only take care of shelves but also of sticky windows so you can just set it sticky in e and all the other windows will go around it but the window itself will not be tiled and not be set floating. I'm going to use your module everyday, so expect somo bug report... :) Great :-). Best regards, Michael PS: Please CC the mailinglist. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] updated: three new edje embryo functions
Hi
Attached patch adds three new functions to edje/embryo, namely
part_raise, part_lower and get_mouse_buttons.
The patch has been updated to apply cleanly against latest cvs.
Regrads
Lars Munch
Index: data/include/edje.inc
===
RCS file: /var/cvs/e/e17/libs/edje/data/include/edje.inc,v
retrieving revision 1.24
diff -u -r1.24 edje.inc
--- data/include/edje.inc 11 Apr 2008 23:36:35 - 1.24
+++ data/include/edje.inc 13 Apr 2008 10:11:05 -
@@ -104,10 +104,13 @@
native get_text_class (class[], font[], Float:size);
native get_geometry (part_id, x, y, w, h);
native get_mouse(x, y);
+native get_mouse_buttons();
native stop_program (program_id);
native stop_programs_on (part_id);
native set_min_size (Float:w, Float:h);
native set_max_size (Float:w, Float:h);
+native part_raise (part_id);
+native part_lower (part_id);
native part_swallow (part_id, GROUP:str[]);
enum Msg_Type
Index: src/lib/edje_embryo.c
===
RCS file: /var/cvs/e/e17/libs/edje/src/lib/edje_embryo.c,v
retrieving revision 1.60
diff -u -r1.60 edje_embryo.c
--- src/lib/edje_embryo.c 11 Apr 2008 23:36:35 - 1.60
+++ src/lib/edje_embryo.c 13 Apr 2008 10:11:07 -
@@ -174,6 +174,8 @@
* set_clip(part_id, clip_part_id)
* get_clip(part_id)
*
+ * part_raise(part_id)
+ * part_lower(part_id)
* part_swallow(part_id, group_name)
*
* ADD/DEL CUSTOM OBJECTS UNDER SOLE EMBRYO SCRIPT CONTROL
@@ -795,6 +797,17 @@
return 0;
}
+/* get_mouse_buttons() */
+static Embryo_Cell
+_edje_embryo_fn_get_mouse_buttons(Embryo_Program *ep, Embryo_Cell *params)
+{
+ Edje *ed;
+
+ CHKPARAM(0);
+ ed = embryo_program_data_get(ep);
+ return evas_pointer_button_down_mask_get(ed-evas);
+}
+
/* emit(sig[], src[]) */
static Embryo_Cell
_edje_embryo_fn_emit(Embryo_Program *ep, Embryo_Cell *params)
@@ -2130,6 +2143,44 @@
return 0;
}
+/* part_raise(part_id) */
+static Embryo_Cell
+_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params)
+{
+ int part_id = 0;
+ Edje *ed;
+
+ CHKPARAM(1);
+
+ part_id = params[1];
+ if (part_id 0) return 0;
+
+ ed = embryo_program_data_get(ep);
+
+ evas_object_raise(ed-obj);
+
+ return 0;
+}
+
+/* part_lower(part_id) */
+static Embryo_Cell
+_edje_embryo_fn_part_lower(Embryo_Program *ep, Embryo_Cell *params)
+{
+ int part_id = 0;
+ Edje *ed;
+
+ CHKPARAM(1);
+
+ part_id = params[1];
+ if (part_id 0) return 0;
+
+ ed = embryo_program_data_get(ep);
+
+ evas_object_lower(ed-obj);
+
+ return 0;
+}
+
/* part_swallow(part_id, group_name) */
static Embryo_Cell
_edje_embryo_fn_part_swallow(Embryo_Program *ep, Embryo_Cell *params)
@@ -2229,6 +2280,7 @@
embryo_program_native_call_add(ep, get_drag_page, _edje_embryo_fn_get_drag_page);
embryo_program_native_call_add(ep, set_drag_page, _edje_embryo_fn_set_drag_page);
embryo_program_native_call_add(ep, get_mouse, _edje_embryo_fn_get_mouse);
+ embryo_program_native_call_add(ep, get_mouse_buttons, _edje_embryo_fn_get_mouse_buttons);
embryo_program_native_call_add(ep, stop_program, _edje_embryo_fn_stop_program);
embryo_program_native_call_add(ep, stop_programs_on, _edje_embryo_fn_stop_programs_on);
embryo_program_native_call_add(ep, set_min_size, _edje_embryo_fn_set_min_size);
@@ -2240,6 +2292,8 @@
embryo_program_native_call_add(ep, set_state_val, _edje_embryo_fn_set_state_val);
embryo_program_native_call_add(ep, get_state_val, _edje_embryo_fn_get_state_val);
+ embryo_program_native_call_add(ep, part_raise, _edje_embryo_fn_part_raise);
+ embryo_program_native_call_add(ep, part_lower, _edje_embryo_fn_part_lower);
embryo_program_native_call_add(ep, part_swallow, _edje_embryo_fn_part_swallow);
// embryo_program_vm_push(ed-collection-script);
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: Re: Tiling module for e17
- Michael Stapelberg [EMAIL PROTECTED] ha scritto: Hi Dave, * [13.04.08 03:37]: Hi, really a good module !! good work This version works well on my machine, also my xterm problem seem solved :) Thanks, good to hear :-). You should add an X-Enlightenment-ModuleType=system line to the module.desktop.in file to make the module appear in the right category on the module setting dialog. Is system the right category for you? Oh, thanks for the hint. I forgot this one. appearance is the more appropriate category, I think. New Revision is in the git repositories. In my opinion we can commit the patch for e as it's really simple and brake free, so to make testing easier. Yes, I think so, too. Anyone got CVS access and is willing to put the following patch in please? http://staff.get-e.org/?p=users/michael/e17-tiling.git/.git;a=blob_plain;f=desk.patch;hb=d1ff98e8d9de4cce37fa1643885413c0401b73e2 Also I think your module should replace the really too much simple layout internal module once it is stable enought. I think this one is to be used for something different (e17 on embedded devices), however let raster speak on this ;-). Now a feature request: the ability to set a border for the desktop that will not be covered by tiling, for example top 10px, left 100px... This is usefull if you have other staff than shelf around your desktop, like itask, trayer or module placed on the desktop ;) Ah, I see. I don't use anything like that so I didn't think about it before. Wouldn't the best solution be to integrate everything into shelves as it should be part of your windowmanager anyway? Something is impossible to integrate, like trayer (as we need a better tray spec), and something (like itask) don't make sense in a shelf. One way to fix that would be to let the module not only take care of shelves but also of sticky windows so you can just set it sticky in e and all the other windows will go around it but the window itself will not be tiled and not be set floating. This could be an intresting solution, it will work for trayer, but probably not for itask. Because itask use a trasparent window that is much bigger than the bar itself. My border idea can also be only an estetic preference, you can also want to view a piece of your desktop. We should implement both (sticky and border) to give a user the maximum flexibility. Thanks Dave I'm going to use your module everyday, so expect somo bug report... :) Great :-). Best regards, Michael PS: Please CC the mailinglist. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
Hi Dave, * [13.04.08 14:51]: Something is impossible to integrate, like trayer (as we need a better tray spec), and something (like itask) don't make sense in a shelf. I see. This could be an intresting solution, it will work for trayer, but probably not for itask. Because itask use a trasparent window that is much bigger than the bar itself. I don't exactly see what's the problem then - can't you set transparent windows sticky? My border idea can also be only an estetic preference, you can also want to view a piece of your desktop. We should implement both (sticky and border) to give a user the maximum flexibility. Whilst the sticky thing is relatively easy, I don't (yet) see a general solution to implement not tiling specific areas of the screen and - this is the main problem - the configuration dialog. If you got a good idea how to make this configurable and generic, tell me ;-). Best regards, Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] R: Re: Tiling module for e17
- Michael Stapelberg [EMAIL PROTECTED] ha scritto: Hi Dave, * [13.04.08 14:51]: Something is impossible to integrate, like trayer (as we need a better tray spec), and something (like itask) don't make sense in a shelf. I see. This could be an intresting solution, it will work for trayer, but probably not for itask. Because itask use a trasparent window that is much bigger than the bar itself. I don't exactly see what's the problem then - can't you set transparent windows sticky? The problem is that the itask window is really big (it take pratically half of your screen), also if the bar is really small. See this shot: http://www.gurumeditation.it/e/itask.jpg The black is the itask window. My border idea can also be only an estetic preference, you can also want to view a piece of your desktop. We should implement both (sticky and border) to give a user the maximum flexibility. Whilst the sticky thing is relatively easy, I don't (yet) see a general solution to implement not tiling specific areas of the screen and - this is the main problem - the configuration dialog. If you got a good idea how to make this configurable and generic, tell me ;-). Just the borders, not generic areas. You can make 4 slider for top, bottom, left and right pixels to don't cover. Best regards, Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-04-13 07:09:08 -0700
Build log for Enlightenment DR 0.17 on 2008-04-13 07:09:08 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
Hi Dave, * [13.04.08 16:21]: The problem is that the itask window is really big (it take pratically half of your screen), also if the bar is really small. Hm, does this change if you disable maginification of the icons? Or is this a bug of itask? Just the borders, not generic areas. You can make 4 slider for top, bottom, left and right pixels to don't cover. Well, if there is the possibility to do this for borders, there also should be the possibility to do this for generic areas. Probably the easiest way for now is starting your own git branch and patching it in hard-coded. jeffdameth: Do you have an idea what to do in order to solve this in the best possible way? Best regards, Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
On Sun, Apr 13, 2008 at 3:58 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). Ok, trying to reply to the torrent of ideas from you ;-) No torrent of ideas, just simple basic things that I've already run across and thought might help for you to keep in mind. that was a joke because you replied about 3 times to yourself, adding more ideas :-) - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) you mean because of me? Or because of others? At least raster, if you ask him, he have tons of ideas on how to do things, he have considered almost every case I wondered and the problems come from here: he wants to implement the final super-uber solution to fix them all and he never have time to do it. The only thing that I added to most things were simpler solution to fix part of the problem and improve this later :-P - filter chaining: needs evaluation on good api to negotiate between filters, those that can be done within the matrix (ie: just add to transf matrix), do, others will require the intermediate buffer and will operate on it. So Rotate+Translate+Blur would generate Rotate+Translate in matrix, output a temporary buffer that blur would operate on. This may be suboptimal, but is very easy to work on. - rely on hw-acceleration (shaders and like): it's easy, it's almost everywhere and people are gaining market share by naively using it. We don't even allow users to use it. If you have or not such great hardware, you're unable to use it today. So why not expose this and let users use their hardware? Also, we can still support some of these in software (ie: matrix transf) easily, while others we can simple ignore.Most users (ie: E17) will try to keep with supported-everywhere, avoiding things that might depend on hardware. But others (ie: Rage) could try to use these fancy effects, since they know most of their users will have such hardware. Also, we could use Sure, and that's why things like 'native surfaces' or other methods for custom rendering would be useful - so that people can do those kinds of things if they wish. AFAIU, the idea is already there, just need finishing? (About that other mail) Gallium3D or even go with LLVM directly to get some kind of JIT and have software-only implementation that is highly optimized, without having to care much about it ourselves. All in all, this filter thing is all about exposing some of hardware acceleration without having to explicitly implement it in Evas (as it's done now for things like YUV-RGB conversion, Scale, Colorize, Fade, ...). Actually I was about to go with this individual implementation, like adding evas_object_rotate() and like, but raster and others convinced me that going with a generic filter implementation would be more extensible. Going with super-fast custom case for each of this will span a huge number of function implementations (ie: rotate solid-solid, rotate transp-solid, rotate transp+alpha-solid, ... all of these for C, MMX, SSE, SSE2, Altivec, 16bpp, ...), since this is non-sense for such things that are barely used, let's make it more generic and have the optimizations to be done elsewhere. Well, that sounds great! Looking forward to seeing this finally in evas. :) don't be too excited... it will take time to have someone to do that. Also, we finally have a release plan, no fixed dates yet, but the order is already there: EET, Embryo, Evas, Edje and then E (probably entrance will go earlier?)... so Evas is very close in the list and might get frozen soon, this would have to go in a branch and wait for the next coding window to get in. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Sun, Apr 13, 2008 at 7:17 AM, Lars Munch [EMAIL PROTECTED] wrote:
Hi
Attached patch adds three new functions to edje/embryo, namely
part_raise, part_lower and get_mouse_buttons.
I'd separate get_mouse_buttons() from the others. First of all, they
have nothing to do, second part_*() might be dangerous to use in Edje
parts, I can't see any problem, but I never thought about it too much,
let's wait for raster or someone else to opine here. By having them
separated, the mouse_buttons get in ASAP and the rest will wait for
revision and might not be applied.
As for the implementation, it's not good:
1) lacks get_mouse_buttons() in docs
2) part_*() does not operate on the given part_id:
+static Embryo_Cell
+_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params)
+{
+ int part_id = 0;
no initialization should be done here.
+ ed = embryo_program_data_get(ep);
+
+ evas_object_raise(ed-obj);
where do you use part_id? no where. Maybe you tried to base your code
on other calls that get part_id and they use just like that. But
notice that they use edje_object_*() functions, that get an Edje
object and a part name, so they use part_id to get a rp-part-name.
Since the function you want have no edje_object_*() equivalent, then
you must get the object itself. And not having the
edje_object_part_raise() or edje_object_part_lower() is what make me
wonder if this would break things or not. If they won't break things,
then we should add these and use them from embryo.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
On Sun, Apr 13, 2008 at 11:50 AM, Michael Stapelberg [EMAIL PROTECTED] wrote: Hi Dave, * [13.04.08 16:21]: The problem is that the itask window is really big (it take pratically half of your screen), also if the bar is really small. Hm, does this change if you disable maginification of the icons? Or is this a bug of itask? AFAIR it is smaller, but that doesn't matter much, as the point of using it is to do magnification :-) Also, since I read people wanting this in embedded devices, and I like the idea as well: how does popup dialogs show and is this animated? I never used your module, but I used Illume in OpenMoko, what I see there are tiled applications with dialogs showing in the middle of the screen using a very nice animation (the popup slides in from the top). -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Tiling module for e17
Hi Gustavo, * [13.04.08 18:22]: AFAIR it is smaller, but that doesn't matter much, as the point of using it is to do magnification :-) Ah, so can we just push it in the edge of those fancy graphic stuff noone needs, especially not when using tiling? ;-) Also, since I read people wanting this in embedded devices, and I like the idea as well: how does popup dialogs show and is this animated? I There is an option to exclude dialogs from tiling for exactly this problem. No, there are no animations yet and I haven't planned any. Best regards, Michael - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Caching the result of evas_render_phase1_object_process
On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL [EMAIL PROTECTED] wrote:
Some of you already know, I am working on improving the speed of
evas_render_phase1_object_process. The idea is that the list of
active_object, and object to render will change much between to call
to evas_render.
I started by removing the use of evas_list and use a growing array
of evas_object that is only freed on idle. This does bring only a
small speed improvement. Then I started to cache the result
evas_render_phase1_object_process and keep it alive except on layer
change, show, hide and some color set case. On move and resize I
wanted to just check if the state of stack of call to render_pre is
still valid and call them accordingly. It's almost working. Just the
resize is not. I don't understand why yet, but I can't make it work
the same way as the move. Perhaps someone can help me on understanding
this.
So the code is attached for your fun, but don't commit it or it
will break for sure :-)
After some sleep I found where was the problem and here is an updated
patch that finally work. It improve speed when you don't call
evas_object_show/hide and don't use layer. Each time you call them,
the cache will be droped in other case it will work.
This improvement will complexify the task when we will one day enable
render_pre for smart object as it make the assumption that no
evas_object are modified during call to evas_render_updates_internal.
Please review this patch and test it with your application.
--
Cedric BAIL
diff --git a/src/lib/canvas/evas_main.c b/src/lib/canvas/evas_main.c
index 7313a33..573e386 100644
--- a/src/lib/canvas/evas_main.c
+++ b/src/lib/canvas/evas_main.c
@@ -85,6 +85,8 @@ evas_free(Evas *e)
return;
MAGIC_CHECK_END();
+ if (e-walking_list == 0) evas_render_idle_flush(e);
+
if (e-walking_list 0) return;
del = 1;
e-walking_list++;
diff --git a/src/lib/canvas/evas_object_main.c b/src/lib/canvas/evas_object_main.c
index e5e5fde..1d31f25 100644
--- a/src/lib/canvas/evas_object_main.c
+++ b/src/lib/canvas/evas_object_main.c
@@ -77,6 +77,7 @@ evas_object_change(Evas_Object *obj)
obj-layer-evas-changed = 1;
if (obj-changed) return;
+ evas_render_object_recalc(obj);
obj-changed = 1;
/* set changed flag on all objects this one clips too */
for (l = obj-clip.clipees; l; l = l-next)
@@ -483,6 +484,7 @@ evas_object_del(Evas_Object *obj)
while (obj-clip.clipees) evas_object_clip_unset(obj-clip.clipees-data);
if (obj-cur.clipper) evas_object_clip_unset(obj);
if (obj-smart.smart) evas_object_smart_del(obj);
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
evas_object_event_callback_call(obj, EVAS_CALLBACK_FREE, NULL);
evas_object_smart_cleanup(obj);
obj-delete_me = 1;
@@ -936,6 +938,7 @@ evas_object_show(Evas_Object *obj)
evas_object_inform_call_show(obj);
return;
}
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
obj-cur.visible = 1;
evas_object_change(obj);
evas_object_clip_dirty(obj);
@@ -983,6 +986,7 @@ evas_object_hide(Evas_Object *obj)
evas_object_inform_call_hide(obj);
return;
}
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
obj-cur.visible = 0;
evas_object_change(obj);
evas_object_clip_dirty(obj);
@@ -1096,6 +1100,8 @@ evas_object_color_set(Evas_Object *obj, int r, int g, int b, int a)
obj-cur.color.r = r;
obj-cur.color.g = g;
obj-cur.color.b = b;
+ if ((obj-cur.color.a == 0) || (a == 0))
+ if (obj-layer) evas_render_invalidate(obj-layer-evas);
if ((obj-cur.color.a == 0) (a == 0)) return;
obj-cur.color.a = a;
evas_object_change(obj);
diff --git a/src/lib/canvas/evas_render.c b/src/lib/canvas/evas_render.c
index ccc5c52..2eb7026 100644
--- a/src/lib/canvas/evas_render.c
+++ b/src/lib/canvas/evas_render.c
@@ -4,6 +4,42 @@
static Evas_List *
evas_render_updates_internal(Evas *e, unsigned char make_updates, unsigned char do_draw);
+static inline void
+_evas_object_array_push(Evas_Array *array, Evas_Object *obj)
+{
+ if (!array) return ;
+ if (array-count + 1 array-total)
+ {
+Evas_Object **tmp;
+unsigned int total;
+
+total = array-total + 16;
+tmp = realloc(array-obj, sizeof (Evas_Object*) * total);
+if (!tmp) return ;
+
+array-total = total;
+array-obj = tmp;
+ }
+
+ array-obj[array-count++] = obj;
+}
+
+static void
+_evas_object_array_clean(Evas_Array *array)
+{
+ array-count = 0;
+}
+
+static void
+_evas_object_array_free(Evas_Array *array)
+{
+ array-count = 0;
+ array-total = 0;
+
+ if (array-obj) free(array-obj);
+ array-obj = NULL;
+}
+
/**
* To be documented.
*
@@ -68,24 +104,62 @@ evas_obscured_clear(Evas *e)
}
static void
-_evas_render_phase1_object_process(Evas *e, Evas_Object *obj, Evas_List **active_objects, Evas_List **restack_objects, Evas_List **delete_objects, int restack)
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Sun, Apr 13, 2008 at 01:03:35PM -0300, Gustavo Sverzut Barbieri wrote:
On Sun, Apr 13, 2008 at 7:17 AM, Lars Munch [EMAIL PROTECTED] wrote:
Hi
Attached patch adds three new functions to edje/embryo, namely
part_raise, part_lower and get_mouse_buttons.
I'd separate get_mouse_buttons() from the others. First of all, they
have nothing to do
Your right, I will split the patch up in two.
second part_*() might be dangerous to use in Edje
parts, I can't see any problem, but I never thought about it too much,
let's wait for raster or someone else to opine here. By having them
separated, the mouse_buttons get in ASAP and the rest will wait for
revision and might not be applied.
As for the implementation, it's not good:
1) lacks get_mouse_buttons() in docs
Do you mean in the long list of exported functions at the top of
edje_embryo.c? In that case get_mouse_buttons() is already there. I
guess someone meant to implement it, but never got around to do it.
2) part_*() does not operate on the given part_id:
+static Embryo_Cell
+_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params)
+{
+ int part_id = 0;
no initialization should be done here.
+ ed = embryo_program_data_get(ep);
+
+ evas_object_raise(ed-obj);
where do you use part_id? no where. Maybe you tried to base your code
on other calls that get part_id and they use just like that. But
notice that they use edje_object_*() functions, that get an Edje
object and a part name, so they use part_id to get a rp-part-name.
Since the function you want have no edje_object_*() equivalent, then
you must get the object itself. And not having the
edje_object_part_raise() or edje_object_part_lower() is what make me
wonder if this would break things or not. If they won't break things,
then we should add these and use them from embryo.
Yes, it might break things. I just found this comment in the docs for
edje_object_part_object_get() You should never modify the state of the
returned object (with evas_object_move() or evas_object_hide() for
example). I will dig a little deaper and see what I can find.
Thanks for the review.
-- Lars Munch
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] Caching the result of evas_render_phase1_object_process
On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL [EMAIL PROTECTED] wrote: Some of you already know, I am working on improving the speed of evas_render_phase1_object_process. The idea is that the list of active_object, and object to render will change much between to call to evas_render. I started by removing the use of evas_list and use a growing array of evas_object that is only freed on idle. This does bring only a small speed improvement. Then I started to cache the result evas_render_phase1_object_process and keep it alive except on layer change, show, hide and some color set case. On move and resize I wanted to just check if the state of stack of call to render_pre is still valid and call them accordingly. It's almost working. Just the resize is not. I don't understand why yet, but I can't make it work the same way as the move. Perhaps someone can help me on understanding this. So the code is attached for your fun, but don't commit it or it will break for sure :-) After some sleep I found where was the problem and here is an updated patch that finally work. It improve speed when you don't call evas_object_show/hide and don't use layer. Each time you call them, the cache will be droped in other case it will work. This improvement will complexify the task when we will one day enable render_pre for smart object as it make the assumption that no evas_object are modified during call to evas_render_updates_internal. Please review this patch and test it with your application. no time to test it now, but an overview is: - good, seems to break nothing (as you said); - my general remarks to your coding style: try to avoid aligning variable declaration, it's not used in E and it causes patches to be dirtier than they need to (changes that just change this). I also dislike the return ; (with the space) ;-) - my general remarks about patches: try to avoid useless changes, like changing tabs-spaces and removing trailing white spaces, do it in separate patch before (now you have commit access, just commit these before you play!) - evas_array seems very useful, make it available to evas as a whole! Just have it to take void * and it will do just fine. Also, I'd make the increase amount (16) configurable after the array is created (or provide an alternative constructor). - I'd remove the calls to really do things (ie: e-engine.func-output_redraws_rect_del()) from _evas_render_phase1_object_process(), just call _evas_render_phase1_direct() after you built the array... I think this separation will be good and will no cause any damage to performance). OTH, if you want to have performance no matter what, then keep it as is by carry the should not cache flag (clean_them), in that case you'd not add to the array at all. as you can see, just minor things. It looks very great so far! PS: do you have the improvements in numbers? Would rock to present it as a chart, let's also make it public somewhere. (I regret for not doing that for the optimizations I did) -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
On Sun, Apr 13, 2008 at 2:47 PM, Lars Munch [EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 01:03:35PM -0300, Gustavo Sverzut Barbieri wrote:
2) part_*() does not operate on the given part_id:
+static Embryo_Cell
+_edje_embryo_fn_part_raise(Embryo_Program *ep, Embryo_Cell *params)
+{
+ int part_id = 0;
no initialization should be done here.
+ ed = embryo_program_data_get(ep);
+
+ evas_object_raise(ed-obj);
where do you use part_id? no where. Maybe you tried to base your code
on other calls that get part_id and they use just like that. But
notice that they use edje_object_*() functions, that get an Edje
object and a part name, so they use part_id to get a rp-part-name.
Since the function you want have no edje_object_*() equivalent, then
you must get the object itself. And not having the
edje_object_part_raise() or edje_object_part_lower() is what make me
wonder if this would break things or not. If they won't break things,
then we should add these and use them from embryo.
Yes, it might break things. I just found this comment in the docs for
edje_object_part_object_get() You should never modify the state of the
returned object (with evas_object_move() or evas_object_hide() for
example). I will dig a little deaper and see what I can find.
Yes.
Maybe it will not impact things. The problem with these calls is that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}()) and
expose it from embryo.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] updated: three new edje embryo functions
Gustavo Sverzut Barbieri schrieb:
Maybe it will not impact things. The problem with these calls is that
they would collide with Edje internal states, getting these
inconsistent. But since Edje does not handle any layer/stack-related
information in their states, maybe this is no problem, in this case
just add the call to edje C api (edje_object_part_{raise,lower}()) and
expose it from embryo.
I don't think it is a good idea to have those functions in the edje c
api. The application should change directly the theme. That's why there
isn't a edje_object_part_state_set() function.
Peter
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) you mean because of me? Or because of others? At least raster, if you ask him, he have tons of ideas on how to do things, he have considered almost every case I wondered and the problems come from here: he wants to implement the final super-uber solution to fix them all and he never have time to do it. The only thing that I added to most things were simpler solution to fix part of the problem and improve this later :-P Is that right.. Well now raster you evil man!! :) Well, that sounds great! Looking forward to seeing this finally in evas. :) don't be too excited... it will take time to have someone to do that. What! I thought you were working on this full-steam ahead.. Carsten said that's what you were doing! You're going to have to speak with him about it.. slap him around a bit and throw some frozen fish at him, it should do the trick. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
