On Thu, Jun 12, 2008 at 10:28 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > I wrote: >>> 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. > > Let's take a slightly different view on this and let's imagine > for a moment that instead of the current 'poly-point-add' api, one > had to 'set' a list of poly-points. > If one did have this, it would make it much easier to deal with > the various ambiguities/inconsistencies of poly objs, because the main > source of 'issues' really comes from mixing of calls to move/resize and > calls to 'add' a point to an existing set. Indeed, it would be possible > to support setting various kinds of poly-points, either concrete canvas > coords ones and abstract [0,1] coord based ones as Cedric mentioned.. > and each would have its own well-defined semantics.
That will definitively be a better idea, their would not be any more question around what shoud we do when an evas_object_move or evas_object_resize is done between two call to point_add. > This actually brings up an issue which is relevant to poly objs > as well, ie. of a 'good' software implementation for aa 'drawing' of > polys, paths, ... > > There are many such implementations (good or bad) around, I may > even have one or two buried somewhere, but for this I think a good > start would be some work that's in the "enesim" lib (though I think > what's there is from somewhere else). I'd say it might be a good idea > to see if the implementation there could be used in evas for its poly > filling. > > Whether enesim, or something like it, could/should be used as > an (external) engine for evas' software gfx is an interesting question. > But if so, then it would be useful to slowly try to make both ends > meet.. hence this would be a good start. And if not, then at least > evas might benefit from a better poly filling implementation. I think both change are needed internal implementation and external API. I have some idea for the GL engine but absolutly not for the software implementation. So we could start by changing the external API and then update it's internal by having a much better/faster software implementation. And it would be cool if we can reuse the work that as already be done by other, and well done. -- 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
