On Mon, Mar 3, 2008 at 8:41 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > 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.
I just said that because earlier discussion on IRC and one of the concerns of doing it in Evas today is slow down Enesim development. > > 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. [...] > 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. I agree with use case of fixed filters, actually the proposed filters cover more than what I expect. What I disagree is _having_ to implement a span of combinations in order to optimize it for all engines, it will not worth the pain. Ok if one wants to do that, but if we say such feature would just be accepted if this is done we'll never have it. If you like feel free to rephrase it on wiki. -- Gustavo Sverzut Barbieri http://profusion.mobi - Embedded and Mobile Software Development -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
