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).

      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).

      You can still cache the transformed set of poly points at the engine
level, like you're doing with gl, you just need to know when the poly
has changed accordingly so that you then need to re-generate that set from
the original input list of poly points - which I think is something you're
doing anyway.

      BTW, evas should really have an api function that *returns* the
list of polygon points, ie. it needs something like:

Evas_List *
evas_object_polygon_points_get(obj, int *npoints);

or something of that sort. It also needs one that gives the input poly
point's extents, ie. something like:

void
evas_object_polygon_extents_get(obj, left_x, top_y, right_x, bottom_y);


     Thoughts or comments? 


____________________________________________________________
Stop foreclosure.  Click here to stay in your home and rebuild credit.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3meXxLg6uVNo8irLPQXVg0bTHbBFGpdHfBL0SOBjbTpFXXZd/

-------------------------------------------------------------------------
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

Reply via email to