On Mon, 3 Mar 2008 08:01:07 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> I'm not sure what "getting e17 out" or enesim have to do with > the particulars of the evas filters/transforms proposals you added to > the wiki. > > How much have you looked into this? You don't need OpenGL > or "gallium3D" for any of the things mentioned above, and in fact > it may well be about the same, or worse, in many circumstances to > do things via those libs - even with decent drivers. > Also, what you proposed was a very generic filter pipeline > mechanism, which though nice in theory may well be fairly counter- > productive or useless to have in practice for most cases that evas > is applied to. You don't need to have a filter mechanism rivaling > Photoshop built-in to evas, or requirements that there be "shaders" > for it to work, and there are more aspects here than just being able > to 'do the gfx', hardware accel or not. > > That said, I think it's great that you want to see things > move forward and all... and who knows, maybe there's lot one can > gain out of trying out your approach to this. In the end though, > Carsten is the maintainer of both evas and edje, and something as > large as this would be best discussed with him. the edje proposals are pretty straightforward. 1. clean up and optimise the code without breaking it. make it faster on embedded as a result. 2. add codec support for video streams (much better than image flipping for when you really need video). this could make edje a direct rival to flash +flv - you could include the controls in the edje video object just like flash. u'd need a web browser plugin - but that'd be an interesting thing. either way we need/want it for our own selfish ends anyway :) 3. future would be more embryo method calls for scripts in edje, more power to the embryo script - eventually giving it full control over anything within an edje object. evas filters is another thing. what i always intended was a fixed filter pipeline. you choose from 1 of N common filters. blur, sharpen, re-color (saturation, brightness, darkness, contrast etc.) and an object - much like clip objects, filters everything it "clips". that simply means passing all objects that are filtered by this object through the filter first before drawing. of course u can optimise, cache filter results etc. software can do this. gaussian blur can have shortcuts. IMHO we need just fixed filters with the ability. yes we can talk about millions of filters that are custom, but lets look at tit a bit. what filters do u really want/need. i always have thought something like: blur (box) blur (gaussian) color-table-remap (4x256 level lookups for rgba color re-mapping for all input) bump map (pixel values determine brightness) sharpen refraction-map (pixels determine hos to source a pixel below and where to put it) and maybe a few others. implement these filters - u can chain one after the other for combining them and you have a lot of ground covered AND can do it in software AND in hardware. most people dont want to go writing their own filters - they are happy to use the ones u have... :) other than that we have rotation to add in. eneism is trying to address some of these nuts and bolts, though in the long term. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
