From: Jose G. <jos...@ju...> - 2008-06-13 11:44:02
|
>> 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? :) >> 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'. :) ____________________________________________________________ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m275baV5ho9ezNYUXF3nzJHOnMCL4HNdnXHZ1a6BDmhJRHB/ |