I wrote:
> Cedric wrote:
>
>> Hi,
>>
>> 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.
____________________________________________________________
Click here to find the right stock, bonds, and mutual funds.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mJ0SVKjcoPuU21B3dvpQ4ql71Y9jm8BwjflAsIw3ErwHEgA/
-------------------------------------------------------------------------
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
