Gustavo wrote:
>> PS.
>> Some here would like to have ultimately flexible 'filters'
>> defined via some cpu&gpu supported "shading language" (a kind of
>> gfx scripting mechanism), but I seriously doubt that anyone here
>> is going to spend the time and effort required to design and
>> implement such a thing for evas. Thus, if evas' filters/transforms
>> system is designed exclusively around such an approach, it would
>> mean a hard dependence on eith gl-shaders or gallium3d or some
>> such lib that would offer this functionality.
>> I believe this should be an option.. ie. an optionally
>> compiled, loadable ability, not a built-in requirement for evas
>> just to allow for geometric transforms, especially since these
>> are so easily obtained with software and readily supported in
>> xrender and gl.
>>
>
> The point of it being generic, at least for ME (not we, don't care
> about others agreeing or not) is to enable you to write such filters
> and plug them. You write then, you just have to implement the API and
> you're done. If you want to set a matrix, you specify it and you set
>
Ok, sure. But how does one implement the filters.. how do you
do it so that the filters will then work with any obj, any evas, etc.
One can imagine 'filters' as engine dependent modules of some sort,
and then you can use whatever for implementing each.. gl shaders,
software span functions, etc. Generally speaking though, most of
this will work for filters that will apply to image surfaces of given
types. One can also try and have an even more abstract gfx 'api' like
shading languages provide, and map such to the rendering backends -
but that's a lot more work.
> it. If you want to be dependent on GL, do it on your code, use it from
> your application.
>
>
That was the whole point of at least having 'native surfaces'
for image objs - so one could render to such surfaces via whatever
specific apis one wants that could support rendering to those.
Then, if one wants to use gl-shaders to do stuff on a gl texture..
great.. One could even use such gl stuff on an xrender native surface
by getting a texture from the pixmap associated with a picture, etc.
Lots of possibilities available for quite custom rendering to such
buffers (and best utilized as part of smart objs with render-pre/post
functions, and of course also via a more direct dst surface rendering
mechanism).
> Of course Evas should provide some good one, generic, by default. But
> I'll not work on this now (maybe in future). But so far what I want is
> to (_very rough_ draft of the possible API):
>
>
Ok, but before we go on with this, let's note that there are
(at least) three different ways one can imagine things like "filters"
in evas:
1. One can consider filters as certain evas objects that modify the
rendered region 'beneath' them (ie. in stacking order, over some
region they define).
This is what things like mini/magni-fication filters do, or say
a blur obj that blurs the region beneath where a such an object would
be placed (BTW, Hisham once implemented something like that for evas,
for the software engines only.. or at least I seem to recall something
like that long ago). This is potentially very interesting.
2. One can consider filters as certain modifiers which affect how
a given evas object will be rendered.
Now of course one can think of just about anything that way
(including move, resize, color, whatnot) and it's not always useful
to express everything that way.. but as you mention, one should leave
open the ability to define new such kinds of filters.
These are somewhat wider in scope than the above (1) since one can
potentially have filters that affect only certain kinds of objects
(eg. text-styles, or even fonts, can be considered as filters on text
objs.. some may or may not make much sense on other types of objs).
In general, for a given set of structured data (objs), we can
have 'filters' that are natural to it, and some that are not (but
may be for others).
This is in part some of the problem we have with things like smart
objs.. we even have an ambiguity with simple things like setting the
color of such objs - right now we usually color each member (not much
else we can do), but one could also want to color the obj as a whole
(eg. as if the smart obj were rendered to a buffer evas and that image
were colored). The same kind of 'issue' will come up with even more
general 'filters' - even those that are geometric or raster-image-
modifiers in nature.
3. One can consider filters as part of an immediate-mode api that
allows one to affect other immediate-mode rendering primitives,
and use such for custom rendering (to native surfaces say).
There, one's able to use whatever may already exist that's
appropriate.
.... I'll try and get back to the rest of your reply once I get
a chance to sleep some - but much of it is a lot like what I also
had in mind. :)
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
