[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] ewl layer handling

On 4/15/06, Peter Wehrfritz <peter.wehrfritz@web.de> wrote:
> Hi all,
> While I'm playing around with ewl_embed to replace my old context menu
> in elitaire, I recognize that this is nearly impossible, because ewl
> spreads its objects over the whole layer range, starting with -1000 upto
> 1000 (I'm not sure if the number are really correct). And swallow it in
> a edje is indeed impossible.

Actually, it can start at any layer, as long as it's set on the smart
object for the embed. The default is -1000.

> So the the current layer system may work well for stand alone ewl apps,
> but it is useless when you want overlap an ewl_embed and some
> evas_objects. I think it would make sense to switch to the "new"
> (perhaps six month old) evas_smart_object layer system, so that every
> ewl widget is a smart member of the ewl_embed smart object and all ewl's
> magic happens in only one layer.

This is certainly a possibility. It might solve some problems we've
also seen with using shaped windows and ewl_embed. The object cache
introduces a few key points that we could use to hook into adding to
the smart object. I have avoided this in the past because of the way
clipping was done in Evas, and the additional memory allocations used
to add an object to a smart object. With the new layering and
clipping, this should be negligible now.

> I know this is not an easy step or an one-day-job, I've already done
> this in elitaire. On the other hand the most code I've seen in ewl
> concerning to layering was put this object over another or put this
> object to the top and that is easily done with stack_above() and raise().

You're mostly correct in how layering is used, but there is a
circumstance where this is not so trivial. The most basic example is a
tooltip, if a window contains a tooltip above some widgets, then a
widget is added that should be stacked above the existing widgets, we
need to maintain the layering of the tooltip above other widgets. The
same situation applies to imenu's. Right now we use a large layer
offset for these types of widgets to make it extremely unlikely that
any new widget will get stacked above them.

I don't think this issue is a show-stopper to your proposed change,
but it does need to be considered and addressed.

> I see two ways to do this:
> 1. Trying to stay as nearly as possible to the current system. E.g. just
> replacing the evas_object_layer_set(o, 1000) with evas_object_raise(o).
> This should be possible but might become tricky in the detail.

IIRC, this is not a hard coded layer setting, except that the default
layer is -1000 or so. It should presently use whatever layer that is
set on the smart object as the starting layer and spread the range of
widgets upward from that point.

> 2. Every widget get a dummy smart object, with no callbacks. So this
> smart object holds in a "normal" widget the clip and the edje theme and
> in the case of a container also the smart object of the children. This
> approach would be cleaner and easier, but I don't know if  it cause
> extra  overhead.

Unfortunately, this could be a lot of overhead. You can potentially
have thousands (millions?) or widgets, so performing extra allocations
like this really adds up. Right now we scale pretty well, and a lot of
the scalability improvements came from the fact that we limit the
number of evas objects to what is presently on screen at any given
time. So the only way I see this being feasible is if we can create
the smart objects at the time of a reveal callback (like we do for the
clip and theme object). That may work, but not if we rely on object
persistence to get layering right.

> Would do you think about it ? Have I  missed anythink or should I try a
> start (without guaranty of success)?

If we can figure out how the issues I mentioned earlier can be
addressed, I would be quite happy to accept a patch for this.

It might be worthwhile to test if adding all of the evas objects to
the embed's smart object solves the issue completely. If the layering
within a smart object is relative to that smart object only and not
the global layering, then there may not be any additional work
required. I can't claim strong knowledge of how the layering works
now, but maybe raster can shed some insight.