From: Carsten H. (T. R. <ra...@ra...> - 2010-09-16 21:25:05
|
On Thu, 16 Sep 2010 18:14:13 -0300 Gustavo Sverzut Barbieri <bar...@pr...> said: > On Thu, Sep 16, 2010 at 5:29 PM, Carsten Haitzler <ra...@ra...> > wrote: > > On Thu, 16 Sep 2010 16:35:39 -0300 Gustavo Sverzut Barbieri > > <bar...@pr...> said: > > > >> On Thu, Sep 16, 2010 at 3:59 PM, Iván Briano (Sachiel) > >> <sac...@gm...> wrote: > >> > Hello people, > >> > > >> > As you know, evas_object_show() and evas_object_hide() control visibility > >> > for Evas_Object's, and when these are called on one, the respective > >> > callbacks (EVAS_CALLBACK_SHOW/HIDE) are triggered. > >> > > >> > Now, this works fine if we want to know when an object is supposed to be > >> > shown or not, but not when something else controls its visibility, like > >> > clippers do. In this > >> > case, we need to do all kinds of checks of who clips whom, when alpha is > >> > 0, etc, just to know if a certain object is actually visible on screen > >> > or not. > >> > > >> > Since Evas does all this things internally and it can notify users of > >> > this kind of > >> > changes, doesn't it make sense to have EVAS_CALLBACK_REALIZED and > >> > EVAS_CALLBACK_UNREALIZED to track them? > >> > >> Indeed it makes sense, problem is when to notify these: > >> > >> 1. render time: as you said, evas knows about these, but makes this > >> analysis at render time. We could call it from there, but it would > >> require a pre-walk of the object to dispatch the callbacks otherwise > >> we'll start re-rendering things again as we callback during render > >> phase :-/ either dangerous (do one pass) or slow (do two passes) > >> > >> 2. clip_set, clip_unset, color_set, show and hide: by that time, > >> evaluate visibility of clipees. Maybe we already do this? Do we flag > >> stuff accordingly? Problem is that this may cause a torrent of > >> callbacks going to user if a whole chain is modified... then we'd need > >> a flag to avoid dispatching callbacks if state did not change? > >> > >> #2 may be the best way... but maybe raster have better ideas? > > > > #2 is better/right - but performance-wise it will be hell :( FIRST we should > > have a "get" call to get "ultimate visibility" - not visibility of the > > object u have but the result of its visibility PLUS color multiplier PLUS > > clipper "ultimate visibility" and so on. when u call the get it can > > evaluate then if flags are dirty, so that's "OK". > > > > the hard bit is how to handle actual notifications when this changes and > > call a callback and not impact perf. > > I'm not that wise into evas render process, but don't you have this > "get" during render phase, so why it would be a performance penalty? > We render much more than we set/unset clippers (under normal > circumstances), problem may be a torrent of changes when deleting a > huge edj object... THATS the problem. the torrent and the repeated walking the tree calling the call on every clippee recursively down the line. i just had a bug the other week where in fixing map i killed perf in opening and closing windows (on a 3ghz desktop it took 2 or so seconds to close a window) as it was walking such a tree up and down and invalidating clips etc. etc. > anyway, if well though and done well we can cut early in the chains as > we find a hidden clipper we can assume everything else is hidden (thus > a recursive list walk checking for flags that changed to new state and > call). sure. as the hidden clipper didnt change - its clippees wont. > BTW, this is required to solve one of the supposed problems with the > global focus-highlight/indicator. There are some cases that would > require this, so far we're ignoring them to get the shit out of the > box ASAP, the public API will remain the same, this will only change > the internals by improving "hide focus indicator if the focused object > is not actually visible", but anyway this is a very stupid corner case > to handle). it's an.. interesting one. maybe focus should skip hidden objects entirely and you only need to figure this out at the time focus is changed, so no need for the callbacks - if it's focus too... you have the focus tree up to the parent etc. so... this can be done efficiently up the focus tree and simply unfuocus that tree branch from that point on if that object is hidden (and then go to next item from the parent). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |