I wrote:
> 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.
>
Though this wouldn't have to be done til later (if desired), let me
suggest a possible semantics for the use of such 'set' transforms on vertex-
based objects like polys.
First of all, I'd limit the transforms to only affine ones (though
I won't into why here - just mentioning it), so if one inputs a transform
with projective components, only the affine part is used.
Then, one would first scale the input vertices according to the poly
obj size but rel to the origin, apply the transform to those points, and
translate forward to its obj position.
So for example if one had input a rectangular poly with vertices
(-50,0), (50, 0), (50, 100), and (-50, 100) thus giving a poly obj at an
initial pos of (-50, 0) of initial size 100x100, and then resizes this
to be 200x200, one'd internally get the vertices (-100, 0), (100, 0),
(100, 200), and (-100, 200). One'd then apply the transform to those
vertices, and lastly translate vertices those by whatever amount would've
brought the un-transformed (but re-sized scaled) poly to the current obj
pos, and one would then render that set of vertices.
Let me also mention yet another possible way to proceed with all this
poly stuff -- just for the sake of argument and completeness.
One *could* keep things as they currently are - ie. keep the 'poly_
point_add' api, keep the fact that poly objs don't respond to obj move
or resizing... and also add such a 'poly_transform_set' api func to take
care of moving,scaling,... (and add a general api func to get any obj's
'effective' bounding rect, ie. after all transforms, things like stroking,
and similar such).
But, I'd only advocate this if one also fixed things so that objects
had the means to 'override' the general obj move/resize functions so that
for vertex-based objects like polys those functions not only did nothing
as far as rendering, but also did not report (via the geometry get) any new
bogus sizes from having being set otherwise.. and this should be consistent
across such vertex-based objs (except rectangles as they are their own kind
of object, similar to, but not exactly a vertex-defined one).
> 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?
>
____________________________________________________________
Enter for Your Chance to WIN*
The TotalBeauty.com Summer Spa Sweepstakes!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UfhtjuLei4TUSDMz2Z9ssSotS7UWljnj3yyEKgk3ZKDmtS/
-------------------------------------------------------------------------
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
