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

Reply via email to