>>> 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.
>
>
The current state of things with polys is pretty dismal, it really
needs changing to allow for move/resize to 'work', most would likely agree
with that.
The way of "minimal breakage" would be to keep the current semantics
for poly points and for 'adding' such points, but just making sure the
implementation does this in a manner consistent with move/resizing (where
resizing is interpreted as scaling of the poly points). This is very easy
to do, so long as we keep the poly as input -- let further vertex transforms
(translations or otherwise) be dealt with on top of that.
But other ways (including some of the other options mentioned here
by both of us) are possible and each has its own pros and cons.. probably
the best way to choose is to look into what might be most useful.
As far as the engines go.. well, it would be best if engine funcs
all had a similar 'form' to the objs' api funcs, and there were engine
level obj drawing funcs of similar form as well... but even without that
for now one can still get away with it for 'improved' polys by calculating
the set of transformed (moved/scaled for now) poly points form the input
ones and pass that to current poly drawing func, and only re-do such
calculations when relevant state changes (ie. points added, obj moved
or resized).
Have to run for now... more on this a bit later. :)
____________________________________________________________
Click here to find the right tools for any job!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nkkkJByZo4i4wDYpD9OuMe3SHhKlgpuT4XjvG2J4nppUbZ1/
-------------------------------------------------------------------------
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
