On Wed, Jun 11, 2008 at 11:01 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > I wrote: >> Cedric wrote: >>> I wanted to improve evas polygons. In the current situation, we >>> need to setup and destroy each polygon every time we call evas_render. >>> It would be nice to make it survive during two call to evas_render and >>> being able to modify it a little bit. Moving it around and adding >>> point would be nice to have. So here is a patch that just give this >>> possibility. Older code should still work fine, but as I only know one >>> app that use it (expedite) I need your comment on this stuff. >>> >>> Of course, this improve speed for the OpenGL engine from something >>> around 650 to something around 800. >>> >>> As always have fun with this patch :-) >> It's a nice idea and long overdue :) I think there may be some >> problems with this.. not sure though, maybe not - need to look at it >> a bit. But anyway, I like the approach and improvements. >> I recall doing something like this once, and subsequently not >> liking the implications. Part of the problem I see with this particular >> kind of semantics is that it makes it difficult to keep track of just >> what are the actual points that comprise "the" polygon, and this is >> desirable for certain reasons. >> >> Here's an alternative proposal with an even simpler implementation: >> >> We take the poly points as being defined in their own coordinate system, >> which happens to agree with the canvas coordinate system. Moving the >> polygon will affect where the poly is rendered but not the list of poly >> points itself. The geometry of the object will depend on the geometry >> of the poly points (in their coordinate system), plus whatever the poly >> obj's translation (more would need to be done with transforms, but not >> right now). >> So, one keeps the list of poly points as input, gets their extents, >> uses that and the current obj state (position) to get the current obj's >> extent, and renders the poly points at whatever dst point (obj transforms >> can be dealt with later, but note that one can transform the poly points >> separately from transforming, or applying-a-filter-to, the poly objec). > > Just to clarify this a bit here: When adding a poly point, one > might effectively move the object, namely say from cur.x to cur.x + dx > where dx would be say the new point's x minus the current poly leftmost x, > if the new point's x is less than the old leftmost x, and similarly one > might change its width, etc. > However, this kind of semantics (as with the current one) has some > problems with the idea of "re-sizing the poly obj scales it" unless one > is careful (see below).
>> Note that we also have not dealt with things like: What does it mean >> to re-size the poly object? Right now this is confusing - setting the obj >> size will give a new size, but does nothing to affect the poly itself. >> I think it would be good if it *scaled* the polygon.. and for that one >> needs to have the original set of input poly points or precision errors >> would ensue (and the same goes for transforms applied to the poly points). > > There are couple of 'issues' with this though, one being the choice > of origin from which to scale - one could use the obj's current pos, so > the obj would change in size but not position, or one could use the poly's > coordinate system origin, which would change both the obj pos and size. > > The other issue would be the consistency of this interpretation with > the intrinsic action that adding points causes to changes in pos/size of > the object, as mentioned above. > It would seem that if one really wanted obj resizing to scale the > polygon and not conflict with effects of resizing with point addition, > then adding points should not determine the pos/size of the object > at all.. it would only determine the pos/size (ie. extents) of the poly > in its own coordinate system, which one should be able to query, but > one would still need to both move and resize the object as desired. > Alternatively, one can keep the effect of adding points as possibly > modifying obj pos/size, but one must do so more carefully so as to take > into account the current set obj size vs the poly's intrinsic size - > ie. adding a point would change its intrinsic size, and this would cause > a change of the obj size by the suitable scaling factor obtained from > the current set size, etc.. and this might be a more suitable semantics. I am definitively for breaking Evas_Object Polygon API. It would be really easier if it was more a classic Evas_Object, I really want to have move/resize working with it. It will be easier to use and to integrate in other application (like edje). It should help us have a faster implementation also, by caching more easily the result. My prefered way would be by having all points coordinates expressed inside the polygon geometry. Between 0.0 and 1.0 would be nice, but then evas would need floating point, perhaps not something we really want. Another possibility would be to just set a virtual geometry for the polygon and do the transformation when giving the point to the engine. The big problem of this change is the break in the Evas API, the change in the engine are minimal. But the change in the semantic of the Evas API will break all evas application using polygons. So we need to hear opinion from people using it. They are really few user of this feature, so sooner we breake it, less people will be impacted. So please raise your voice on this subject. -- Cedric BAIL ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
