On Fri, Aug 7, 2009 at 5:30 PM, Christopher Michael<cpmicha...@comcast.net> wrote: > Gustavo Sverzut Barbieri wrote: >> >> On Fri, Aug 7, 2009 at 9:37 AM, Cedric BAIL<cedric.b...@free.fr> wrote: >>> >>> On Fri, Aug 7, 2009 at 1:35 PM, Christopher >>> Michael<cpmicha...@comcast.net> wrote: >>>> >>>> While doing some digging as to why evas_object_resize was taking a lot >>>> longer than evas_object_move, I noticed that evas_object_move is NOT >>>> calling >>>> evas_object_recalc_clippees unless the obj->layer->evas->events_frozen >>>> <= 0. >>>> >>>> I compared the code with what is in evas_object_resize and noticed that >>>> evas_object_resize is calling evas_object_recalc_clippees regardless if >>>> events were frozen or not. I've attached a patch that makes >>>> evas_object_resize work like evas_object_move in this regard. >>>> >>>> I have tested this patch with E and also with Elementary and did not >>>> notice >>>> any artifacts or problems. >>>> >>>> I currently do not have ewl or etk installed so I did not test with >>>> those, >>>> but if someone else has those installed and is brave enough, please feel >>>> free to test this patch. >>> >>> I did test it locally with my own programs, and this change sounds good >>> to me. >>> >>>> I did NOT do a direct commit on this as evas is a very core part of EFL >>>> and >>>> I did not want to purposely break things without 1) more testing & 2) >>>> confirmation/approval from people that know evas better than myself... >>> >>> I will vote for a commit with a big comment stating that it could >>> create glitch on screen and we will revert if someone report a >>> breakage. >> >> I guess this comment is not even required, if nobody complains in few >> days then there should be no problem... if people do we'll know what >> it is. >> >> but clearly this was a "forgotten" thing and the patch is correct. >> > Ok, since it seems that the general consensus is to apply this, then I will > commit the fix with the suggested comments. Thank you guys for taking a look > at it :) I'm not entirely sure how much of a speed up for resizing that this > will actually give, but it keeps the code inline with what happens in a > 'move' and should avoid needless clippees recalc wrt evas events being > frozen.
I wonder why clippees should be recalculated outside evas_render (and variants) at all. Raster, do you care to say why do we need this? AFAIU they're just used at render. > I've also noticed a few places in the same evas_object_main.c file where > code could be consolidated. As I dig deeper into why resizes are (imo) slow > (granted not noticeably, but certainly not optimized), I may do some > consolidation there...but in order to keep things in working order, I will > more than likely send them as patches rather than direct commits (to be on > the safe side). As raster usually says: test, works? commit. If it break we can always revert it later. I have to agree... and if you just test yourself and test people (ie: me, cedric) to test, it'll probably not cover all cases, so commit soon to SVN if its is NOT the freeze period, if it break we'll know and fix soon. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
