>> 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/
-------------------------------------------------------------------------
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
