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
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] [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] [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 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] Async events API
On Sat, Apr 12, 2008 at 2:37 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > no need to make it blocking :) look at ecore_con - hell look at emotion. it's Well, I looked at emotion and damn, it's wrong! :-P Ok, it will work for most of the cases where you are within the buffer size, but then it would also not block if you're in the same situation and have not set the non-blocking flag. The problem is at the border condition: full buffer: - blocking would block the call and make the sender process (in this case, the thread) to block a while... IMO this is not so bad, as the main process is not being capable of reading it at all. - non-blocking would write partial and stay looping to write the remaining bytes... so blocking the same way, or it would do a partial write if you don't loop. Also, on the read side, depending on the implementation it would either loop (so blocking) waiting for data or do partial reads (as it might do with Emotion), these partial reads are the damn bug-causing I'm talking about. read() and write() does not do all the work for us because these are really low level functions enabling us to do such a looping solution (that blocks in any way) or queueing the data elsewhere (todo-buffers) and doing something else if the read/write fails... but doing these todo-buffers is really a PITA, I never see nobody using them, maybe these are used in some high-performance servers that can keep todo-buffers for each socket and try to dispatch other sockets if some are blocked. Just read emotion code and consider: - Thread 1: write 3xmessage-size bytes (consider message-size being 2 bytes: [AA|BB|CC]) - Thread 2: read message-size bytes [AA], then read 1 byte [B]... it's not of message-size bytes, then discard (!!!) and try to read message-size bytes again, which you can do because you still have 3 bytes there, so you end with [BC], then you process this wrong pointer and then read message-size again, being unable because just [C] is there. I don't even want to read ecore_con! If it resemble emotion then it's wrong and it might incur in security risk for all code using it... The risky is not that important since you don't handle pointers to a process to another, just between threads, and nobody would replace a thread... :-P What also makes me wonder: why not make this kind of thing available in ecore? Just handle read/write file descriptors to a function to have these configured (maybe also set the buffer size based on message size) and provide ecore_read() and ecore_write() with these loops all handled? This is way better than spreading these weird loops all over the code, many can be just wrong and will spread bugs :-/ > all done with non-blocking. for emotion i used void *'s to write that point > to > he message. it works by handing the pointer to a msg struct from the slave > thread to the main one - it's quite handy that way. it's also generic as i > can > pass anything along from a slave to a master thread - just point to it :) the > difference between a byte and a void * won't really be anything worth talking > about as u are unlikely to pass 1000's of them at a time - even if u do, > kernel buffers are 128k by default - that's 32k messages on 32bit and 16k on > 16bit that u can buffer before draining... that's a LOOOT. I guess you mean 16K on 64bit... :-) Ok, your example fits into the buffer size exactly, but we shouldn't trust this to be always true. Also, as I tried to show, the blocking code would just do the same thing and make the error-handling easier. -- 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] [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 *
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] 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] [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] 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] 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
[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
[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
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 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
[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
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
