I would really appreciate some help with the issue detailed below, as I think it is important to fix this before the release (it makes exporting of images using blur a bit questionable, reducing blur's usefulness).
I filed a bug in the SF bug tracker btw. (nr. 1631016)
Jasper van de Gronde wrote:
Niko Kiirala wrote:
Fri, 05 Jan 2007 23:22:51 +0100 Jasper van de Gronde <th.v.d.gronde@...528...> kirjoitti:
In any case, I tried making this work but somehow couldn't figure out how to do it correctly, so if anyone knows how to do this (or knows of a better way to fix this problem) that would be great. As far as I can see nr_arena_item_invoke_render is where the borders for gaussian blur are added to the rendered area and then clipped to a bounding box. My guess is that the following line shouldn't be there: nr_rect_l_intersect (&carea, &carea, &item->bbox); But simply commenting that out gives weird results (if I remember correctly the exported image got borders around it and the artifacts remained).
Now, as far as I know, it is justified to clip to bounding box: due to it's nature, an object does not expand outside the bounding box. That is, if we take any point that lies outside the bounding box, it will be completely transparent.
Yes, but when using blur pixels within the bounding box depend on pixels outside the bounding box of the visible area (and in this particular case they can be pretty far outside the bounding box). What Inkscape does (if I read the code correctly) is:
- Clip the object area to the visible area.
- Take the above into account using the get_enlarge method.
- Clip the calculated area AGAIN!
Now, the last step can't possibly be right if I interpreted it correctly, it would defeat the purpose of get_enlarge whenever an object is close to the edge of the visible area (and the resulting artifacts do seem to point in that direction).
Well, those bbox calculations have to be revised anyway, as filter effects area (which must be accounted for in item->bbox) is now calculated in screen coordinates whereas it should be calculated in object coordinates -> hilarity ensues with rotated / skewed coordinate systems.
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel