Gustavo Sverzut Barbieri wrote: > 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. True true...but (as has become my habit over the years) when it involves a major core EFL lib that I am not an 'expert' with, I usually test here quite a few times then send a patch off to the list for the 'experts' to look at :) I realize this takes a little more time but IMO it's safer for everyone :) nb: the E dev page titles me as a 'Patch Monkey' :)
> 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. > Commit is already in :) dh ------------------------------------------------------------------------------ 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