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 ? >>> 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 ? -- Cedric BAIL ------------------------------------------------------------------------- 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
