Jim, On Mon, Nov 21, 2005 at 04:01:07PM -0500, James Albert wrote: > I have svg files, but my svg renderer is broken right now (new firefox > beta), so I have no idea what they look like. I haven't touched the > code for months.
Hm. Can anyone help out here? It would be very interesting to see what this looks like? > - The classic approach requires direct pixel manipulation. Even a > scaled version needs some kind of pixel testing in order to do the > boundaries and gaps correctly. We currently maintain a scaled and an unscaled image to do this (this is noticeable if you use the kernel call 'Show()' to switch to the priority map: You will then be shown a 320x190 priority map, even if you're using scaled background images, though it is evident that the visual map employs a more accurate scheme). > - The vector approach is *entirely* mathematical. There's no actual > pixel buffer, so there's no way to do pixel testing, because there are > no pixels. Well, matrices are mathematical constructions, too... ;-) > My best solution so far (and the one I'm currently using), is to render > both the vector and classical versions at the same time in a sort of > hybrid approach. Makes sense... [...] > Basically I render the pic as usual, but I also store the geometry > data. This way, when I do a fill it can look at what the output is > supposed to be and go "oh, I shouldn't fill here" without resorting to > really complex vector mathematics. The problem I'm having here is > coming up with a hybrid flood fill/triangulation algorithm - if that > even makes sense. I'm not sure if I see all of the issue here, but rest assured that I believe you if you say that it's not easy ;-) [...] I'm afraid that I can't offer any advice on these issues at the moment. > So basically, it has potential, and it's a safer and more > straightforward method then dealing with image scaling, but it still > needs a lot of work. Sounds good! I completely agree that translating from the flood-filled world to the world of vector graphics is much preferrable, for many reasons (it also allows us to do a few more tricks with rendering the picture afterwards). In particular, we can use this approach for pic rendering independently of an OpenGL graphics driver. -- Christoph _______________________________________________ FreeSCI-develop mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freesci-develop
