Just a quick update this time, I haven't finished anything especially noteworthy lately, so I haven't blogged about them either. The bugs mentioned in my last post have been ironed out, as well as some others. I did make the blur slider such that it didn't create a full new filter every time it was invoked, but as I committed that change, it became apparent that Nicholas Bishop had been working on the same code for his GSoC project on filter effects UI. So, that my code was obsoleted in a matter of hours. Re-implementing it, so it can work with this new blur & blending mode UI, could be useful though.
My plans now are to implement new filter primitives. My original plan states feMerge and feComposite, but as turbulence and lighting effects were considered really useful, when I discussed this on Inkscape Jabber channel, I might implement them first.
Monday, 25 June 2007
Tuesday, 12 June 2007
Dropshadows with filters
Today I had my last exam this semester. Well, sort of. Actually this semester ended already in the beginning of May and this was just a chance to retake exams. Anyhow, the test was on Design of Algorithms. In itself, this is really an interesting area of computing science and I'm planning to do my master's studies in the algorithms sub-programme. For this course then, I'm getting a bit frustrated with it. In the first exam I had no idea, how to do operations on binomial heaps, and since that would have given one third of the points, it didn't go well. For this exam then, a quarter of points would have come from remembering an approximate solution to traveling salesman problem, giving at most double the length of ideal solution in polynomial time, and how to prove it won't give longer answers than that. I didn't remember that solution, so this time it won't go too well either. (and I didn't quite have the time to build the solution from scratch... ;)
In coding Inkscape, I had a lot more success. Today I committed code that allows for using SourceAlpha and BackgroundAlpha as input images in filter effects rendering. These are the image of filtered object and its background, but with all colour information stripped out.
I really have no idea, what I could do with BackgroundAlpha, but SourceAlpha at least gives me nice dropshadows. This star here, for example (can you tell, I like using stars as example material?-). It is just a green star, with a filter that takes the BackgroundAlpha image, offsets it by 10 units in both x and y directions, blurs the result and finally blends that image with the original green star.
There are still some oddities with that offset filter. I tried this first without blur, and it resulted in white gaps in the whole shape, which was a known bug for the offset filter. Not good. For my amazement, everything went just fine, when I added the blur. No banding, no spurious messages about trying to reserve almost 16 EiB of memory. I really need to take a better look into what's wrong with that feOffset renderer.
In coding Inkscape, I had a lot more success. Today I committed code that allows for using SourceAlpha and BackgroundAlpha as input images in filter effects rendering. These are the image of filtered object and its background, but with all colour information stripped out.I really have no idea, what I could do with BackgroundAlpha, but SourceAlpha at least gives me nice dropshadows. This star here, for example (can you tell, I like using stars as example material?-). It is just a green star, with a filter that takes the BackgroundAlpha image, offsets it by 10 units in both x and y directions, blurs the result and finally blends that image with the original green star.
There are still some oddities with that offset filter. I tried this first without blur, and it resulted in white gaps in the whole shape, which was a known bug for the offset filter. Not good. For my amazement, everything went just fine, when I added the blur. No banding, no spurious messages about trying to reserve almost 16 EiB of memory. I really need to take a better look into what's wrong with that feOffset renderer.
Wednesday, 6 June 2007
Simple filter, big problems
feOffset is a rather simple filter primitive: it just moves the given image a given distance. If we don't go into sub-pixel rendering accuracy, the framework in Inkscape makes it possible to implement a renderer for this filter by merely updating image location info. So far so good.
What's the problem then? Well, even for simple images rendering this filter requires us to actually render another part of the picture: suppose we wanted to render the rectangle from (x0, y0) to (x1, y1). When we have a feOffset filter with distance (dx, dy), we actually need to render area (x0+dx, y0+dy) (x1+dx, y1+dy) and then apply the filter.
This can be accomplished, rendering blur needs similar functionality and it works quite OK. The bigger problem is, when feOffset is used on background image. In this case, at the time when background is drawn, it's not known, that some filter later on will try to use background outside this area. All the ways to remedy this I can think of, are rather complex. Still, this whole background access functionality is a rather complex subject. It will likely require some kind of re-entrant rendering, that can go back to rendering background when this kind of situation arises.
Also I've spent a way too much time trying to fix background access functionality, that wasn't broken in the first place. Obviously it's dangerous to modify one's own old code, because it's easy to assume remembering its workings. If that was someone else's code, I would have first taken a good look at how it works.
What's the problem then? Well, even for simple images rendering this filter requires us to actually render another part of the picture: suppose we wanted to render the rectangle from (x0, y0) to (x1, y1). When we have a feOffset filter with distance (dx, dy), we actually need to render area (x0+dx, y0+dy) (x1+dx, y1+dy) and then apply the filter.
This can be accomplished, rendering blur needs similar functionality and it works quite OK. The bigger problem is, when feOffset is used on background image. In this case, at the time when background is drawn, it's not known, that some filter later on will try to use background outside this area. All the ways to remedy this I can think of, are rather complex. Still, this whole background access functionality is a rather complex subject. It will likely require some kind of re-entrant rendering, that can go back to rendering background when this kind of situation arises.
Also I've spent a way too much time trying to fix background access functionality, that wasn't broken in the first place. Obviously it's dangerous to modify one's own old code, because it's easy to assume remembering its workings. If that was someone else's code, I would have first taken a good look at how it works.
Subscribe to:
Posts (Atom)