Cedric wrote:
> On Fri, Jun 13, 2008 at 1:40 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
>>>> 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.
>>>
>> I agree, it seems like the best way to go with this. Note
>> that, as I mentioned, one could have the ability to set different
>> kinds of poly-points.. so if one did want to have that (not sure if
>> it's woth it, but just in case), then the 'set' function would
>> need to specify which kind is being set. I think one might as well
>> start with canvas coordinate floating point values for the poly-
>> points, ie. they would represent canvas pixels with sub-pixel coord
>> values as well.. just need to make sure the software drawing routine
>> can do that - eventually anyway.
>>
>> Want to give the api part a shot? :)
>>
>
> As nobody jumped on the discussion, I guess we are the only one
> interrested on this subject. So we are ready to give the API a shot.
> Regarding it, I think expressing it as an array of floating point
> coordinates inside the geometry of the object should be a good way to
> go ? So resizing should work easily that way. And it should also be
> easier to add it to edje also. What's your opinion on this ?
>
>
That would probably be a good way to do it. So, the vertex coords are
floats which correspond to sub-pixel precision canvas coords.
Every time one 'sets' the poly points the previous poly obj geometry
is invalidated and the new one calculated thus determining the obj's size
and pos (top-left corner of int bounding rect).
Moving the poly obj will mean rendering the vertices suitably translated.
Resizing the poly internally scales the vertices by the float fraction of the
new size to the input-poly-size, and presrves the poly obj's pos. This will
again mean rendering the so changed vertices accordingly. Note that this may
have a bit of 'jitter' due to sizes being only integer values.. but one is
also always free to transform the set of vertices as desired and set them
again. In fact, it would eventually be good to have an api function for
setting such a vertex transformation on such objects - say something like
evas_object_polygon_points_transform_set(obj, *t);
where the 't' will be an evas transformation, say possibly an affine and/or
projective transform. This transform will act on the vertices for the purposes
of rendering, but not affect the reported object size or position - though
one would eventually like to have the effective 'bounding rect' of any
transformed obje, whether it's a result of a general object (surface) transform
or of a specilaized vertex transform on certain objects that might support that.
There are other deatils of course, but that should cover most of the
salient 'geometry' related stuff.
>>>> 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.
>>>
>> The use of better software, and/or gl, gfx 'engines', along with
>> external immediate-mode apis for these would be very useful eventually.
>> As to the software drawing routine for poly filling being better/
>> faster... well, 'better' maybe in that it would do aa and sub-pixel
>> precision vertices.. but not faster, no way. The current one is so
>> simple -- it could be made a bit faster here and there, but not by
>> adding aa or supporting sub-pixel precision vertices. The hope is
>> that it would be 'good enough'. :)
>>
>
> Well adding aa would be nice, it could be the default case, but we
> should be able to deactivate it. A little bit like the smooth flag on
> image object I think. So do you have some time to help me work on this
> ?
>
Fortunately, there's already an api function to enable aa:
evas_object_anti_alias_set; which is currently only used by lines and gradients
(in case you don't want smoothing of the way the gradient is rendered, a bit
faster though likely not worth it for most uses.. I should probably get rid
of support for that in grads).
As to helping out.. Sure, I could make some time for that - though as
I mentioned in an earlier email, the 'best' way to do this for now would be
to use what's already there in "enesim". I don't really have time or desire
to dig-out and review some stuff I have on poly rasterization (and I don't
want to use the even older stuff that's in imlib2 since though quite fast
it's limited to integer coord vertices and does a kind of 'thick' filling
that's probably not best here).
Ideally though, Jorge would be the best one to involve here since
enesim is his work and it could a good exercise in helping to 'make both
ends meet' as I mentioned before.. but I don't know how much time he may
for this at the moment. Jorge?
____________________________________________________________
Smart Girls Secret Weapon
Read Unbiased Beauty Product Reviews, Get Helpful Tips, Tricks and Sam
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7U3xc6Ceblua01a95yf84TAmOpETZqKjfWwenwK8oc3pOWL/
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
