On Sat, 25 Aug 2007 04:55:47 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> Hi, > > One guy here at the office was debugging his Smart_Object and noticed > that show() and move() were being called each time when something not > related to his object changed. We isolated the problem and the problem > is caused by how edje is marked dirty and then recalculated. Our test > case was an Edje with our smart object in the bottom and a text on the > top, they were not dependent (rel1 nor rel2), but when the text was > changed, the show/move calls were called on the smart object. edje assumes that evas already is smart about this - and a move and resize are simply "set the state" calls - they do very little. any smart objects should be smart enough to go "oh - that's the same position/size i was already... ignore - return". this allows for simple yet fast code and has worked fine for a long time. > Today, if we have some change, the whole edje is marked as dirty and > then a loop marks both ep->calculated and ep->calculating with > FLAG_NONE, then another look checks for ep->calculated != FLAG_XY and > then triggers recalculation of that part. > > In an ideal world, the changed part should be flagged and recalc > should act on this part and those that depend on it. sure - but doing that is not trivial. it's a fair bit of work. the problem is dependencies go backwards, not forwards. a part says what it depends ON, not a part has a list of what depends on it. if we had that - it'd be easy to just work down from there. > My guess is that trade of common case impact versus difficulties to > implement don't worth it, maybe there is no dependency graph handy, > maybe something else. yup. i kept it simple. edje was complex enough as-is. :) > I see that usually smart objects check for properties and return right > at the beginning if they're exactly the same. But in python bindings > this will result in extra C call, that will trigger python calls and > overhead is bigger there. aaah yeah. in c the expense is tiny - it's actually probably easier and faster than shadowing geometry and avoiding a move/resize. > So, what's the reason for it being like that? Any ideas to improve? Is > that easy or will be a pain? How to get the dependency list? the reason is that all objects, as above, are expected to be vaguely smart (avoid work) and a call in is fast (it's c). > Also, should us avoid calling move()/show() and possible others if > these properties are already the same? I mean this in Edje layer, not > Evas. This would avoid some overhead (although complexity is still > high). i think tilman's patch might be the way to go - and i need to find out what it breaks and why. it shouldnt break anything, if things are done right. > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Jabber: [EMAIL PROTECTED] > MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
