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.
So, does anyone know of a compelling reason why the current
per-point add method is so desirable in evas? This seems more like
something for a complex immediate-mode gfx api that uses that to vary
certain aspects of the drawing context on a per-vertex basis, and not
particularly useful in evas.
Let's also remark to all the vgfx die-hards out there that one
could have as much vgfx in evas as desired in various ways... eg. one
can have a "cairo" object (best done as one example of an object module)
which would essentially give an implicit cairo surface to draw to with
the cairo api - so this would be a kind of gfx-canvas-like object..
and one could also have a simple "path" object (much like the poly obj)
and similar.. it'd basically be a question of a having a good software
implementation for the needed aspects.
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.
Anyone want to look into attempting that?
____________________________________________________________
Take a break - you deserve it. Click here to find a great vacation.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nJgyf77wY0PbIaTO6aQ6fflgWFBUHc45kbgEQlEVIVKunIc/
-------------------------------------------------------------------------
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
