Gustavo wrote:
>> One other aspect that needs to be addressed has to do with the
>> very notion Gustavo mentioned about "negotiating" buffer sizes that
>> a filter/transform might need for putting results to.. and in fact
>> this also covers things like calculating update rects when dealing
>> with these things at the canvas level.
>> The problem is that it may be difficult, in general, to obtain
>> 'bounds' for these kinds of operations on objects.
>>
>
> that's true for other parts as well, and I like raster's
> simplification to "let's keep it to rectangles". Of course we could
> have any shape as clip or dirty area, but it doesn't pay off.
>
> All in all, let's keep areas as a set of rectangles. They're easier to
> operate and provide a good approximation for the first implementation.
> As you said, if calculate the proper coordinates are that difficult,
> then just request for whole-screen buffers and brute force :-P
>
It can be 'difficult' in certain ways, eg. inefficient to
compute or un-intuitive results (translation before or after), etc.
For affine/proj coordinate transforms one can always compute the
target bounds of whatever input rect to transform (the fact is that
one doesn't really transform objects, but rather coordinate systems),
but some transforms make it easier to do that than others (eg. it's
very easy and natural for for affine ones). And remember, these
regions need to be known every time the object might need redrawing..
and it'd be good to keep update areas small if one can make use of
that. :)
For arbitrary filters it'll just have to be the case that
the filter will need to provide a function giving such data..
though actually it's not completely clear if a surface 'filter'
should require a target buffer different in size from the input
surface size for its action. It very much depends on what semantics
one really wants from the concept of 'surface filters'.
But even if one restricts oneself to minimal bounding rects,
for updates and such, there's also the issue of 'picking' to be
dealt with.
When it comes to that, ie. determining if a canvas point is
'inside' the (filtered/transformed) object, there are aspects that
need to be decided if one wants to chain arbitrary such filters.
One will at least need the filter to provide such a 'picking'
function (the point to be tested against being in target space), but
that won't be enough if filters are chained - one will also need the
filters to provide a function to transform a given target point into
a src one, or one'll have to assume the identity function by default.
I imagine this kind of thing isn't done much, that most uses
of surface-filters (ie. image filters) are as a means to affect image
pixels only for the sake of obtaining the desired resulting effect,
even if they do use coordinate transformations as well as sampling
and pixel/color modifications... ie. such 'filters' are mostly
interpreted as image pixel manipulation methods, not as part of a
more detailed user-interface mechanism that needs explicit support
for user/model coordinates.
This is, in part, one reason why I think it's best to keep
affine/proj coordinate transforms separate from a 'filters' notion,
-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
