+2  A: 

You might want to have a look at what JSXGraph is doing, http://jsxgraph.uni-bayreuth.de/wiki/index.php/Category:Examples

If you want the curves to look smooth you probably want to either recalculate the lines depending on the current zoom-factor, or use higher level curve primitives. An example of a static "infinitely" zoomable periodic curve can be seen here: http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/paths-data-02-t.html

You probably want to use a viewBox attribute too, to define the coordinate system and to make the image truly scalable.

Erik Dahlström
I want to follow KISS: It would be great if it were one, single, SVG file, and not a whole page full of scripts. When it comes to http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/paths-data-02-t.html, at a first glance it would appear as if they have solved the problem, but they have not; in fact, they are not even close. The "sine" cure is `<path xmlns="http://www.w3.org/2000/svg" id="Sin_Mqttttz" fill="none" stroke="#FF0000" d="M240 296q25-100 47 0t47 0t47 0t47 0t47 0z"/>`, i.e. it consists of only a handful of points with quadratic Bezier curves between them! This is not nearly
Andreas Rejbrand
...good enough. It looks smooth at any magnification, of course, but it is not an acutal sine curve, only an approximation. And I want to be able to store *any* function curve (or parametric curve) to any resolution, as described in my original post. I mean, the issue with my example SVG file is not that the resolution is too small, but rather the opposite: I think the resolution is 0.0001 (and the x \in [-10, 10]). *If* SVG would work as the AlgoSim internal GDI/OpenGL renderer, it would display the curve smooth at any magnification. But instead SVG magnifies the curves, so that there will be
Andreas Rejbrand
...maybe a thousant overlapping *thick* lines at each point. I guess that this is what makes it look so bad. Or maybe Google Chrome simply magnifies the polyline/path as a bitmap created from the original magnification. I do not know...
Andreas Rejbrand
The width of the stroke is relative to the coordinate system used in the svg. If you want the stroke-width to be exactly one user unit ("pixel") regardless of user agent zoom, then have a look at http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke
Erik Dahlström
@Eric Dahlström: This seems interesting. But Google Chrome appears not to be able to render SVG Tiny documents at all... And, by the way: I thought that SVG Tiny was a *subset* of SVG, aimed at simpler computers, such as cellphones and PDAs. But then: why does SVG Tiny introduce new features, not available in the "full" SVG? Will the next version of SVG allow this "vector-effect" attribute?
Andreas Rejbrand
+1 for the viewBox attribute. I though you had to use the screen coordinate system, but apparently you can define your own. (I learned SVG a few days ago, when I began working with the SVG export routine. Please forgive my ignorance!)
Andreas Rejbrand
Webkit has a patch committed with support for it, http://svn.webkit.org/repository/webkit/trunk/WebCore/ChangeLog. Opera has supported `vector-effect=non-scaling-stroke` since version 9. SVG Tiny 1.2 is not a true subset of SVG 1.1, but it's not that far off, and you can create documents that are valid in both profiles.
Erik Dahlström
+3  A: 

The issue here is the use of a polyline. In any vector-based program you'll likely get similar results because that what a polyline is - a bunch of straight lines that connect to eachother. You should be using a path instead, in particular the segment T (smooth quadratic Bezier curveto).

Your code could to be modified to catch where your control points raise or lower to insert a new Bezier and the result will be much smaller SVG XML with smooth lines. But if that isn't what you want, you could also use a million Bezier's with control points.

Finally, you can consider sub-pixeling. Right now all of your points are whole integers - if the results are floats instead, like 273.534, etc. you may get closer to what you're looking for.

Otaku
+1 for pointing out my stupidity: Of course the coordinates cannot be integers! When converting to the screen coordinate system (when I got the integers), I am loosing a lot of information. In fact, when I wrote the SVG export routine I more or less copied the on-screen (GDI/OpenGL) rendering code. But this actually rerenders the scene when the user zooms, so I actually do fix a zoom level when creating the SVG. How could I ever expect this to scale when zooming the SVG? I am such a moron, sometimes! :) But still, I would like to use the "vector-effect" attribute. It is a pity I cannot in SVG.
Andreas Rejbrand
OK, I have chosen your answer as the accepted answer. I do not think that it answers the actual question, but because it apparently means so much to you, I can live with some confusion.
Andreas Rejbrand
A: 

I just made a stupid mistake. I simply wrote the SVG export routine using the on-screen (GDI/OpenGL) rendering code as a template, and since the GDI code writes to the integer lattice of screen pixels, all coordinates are rounded to the nearest integer. This does not affect the quality at 100 % magnification, but if you zoom in, you get a "noise" applied to the points. When I removed the calls to round, it all works.

See testb.svg and test2b.svg.

Andreas Rejbrand
@Otaku: Because you weren't completely right. The entire first statement ("The issue here is the use of a polyline...") is incorrect; indeed, with a typical resolution of 0.0001, it would be silly not to use straight lines. (This resolution is high, and "...the derivative of sin(x) does not change much if you increase x by 0.0001".)The correct answer would have been "You cannot expect scalability when the points are rounded to the nearest pixels at 100 % magnification, right! :)" Sure, you pointed out this curiosity, but only as a "final remark". For the benefit of the SO readers, it is ...
Andreas Rejbrand
...clearer to explain the problem as I did. (But of course, I did not get back my 250 points by accepting my own answer.) I also feel it would be rather unfair to give away 250 points for a question, the answer of which is that the OP just made a silly mistake.
Andreas Rejbrand
My polylines have no issues at all now (even though the vector-effect stuff probably would be nice). To be honest, I realized my problem before I even read your reply. Please observe your manners. You just downvoted my entire question because I did not award the bounty to you. That's immature. I gave you +1 on your answer, even though -1 would have been reasonable as well, because you missed the main problem and come with irrelevant suggestions.
Andreas Rejbrand
I mean - knowing what I know today, it was wrong to even post the question. I thought that SVG did not work as one would suspect, or that the Google Chrome renderer was faulty. But it turned out to be just a trivial error in the code, so this question has no value to anyone, really. Writing my own answer explaining this makes the confusion smaller.
Andreas Rejbrand
From the context, it is obvious that integer values in [0, 500 (say)] is not what I want. I said that I sample the function at a resolution of 0.0001 and that I therefore expected the image to be "infinitely" scalable. If you know anything about mathematical visualisation, it follows that you need a lot of decimals, at least 4 after the decimal point.
Andreas Rejbrand
Personal attacks on my knowledge of something are not good. Again, please consider acting in respectable manner on this forum.
Otaku
Come on, it obviously is you that is not acting respectable.
Andreas Rejbrand
Now I will take 10 mg oxazepam, and then I will not argue more.
Andreas Rejbrand
Given what I know now, that there is not a problem with SVG, and that my problem was due to a trivial error, how could a reader of SO possibly benefit from this question? Well, if he has made the exactly same mistake as I did (forgetting to remove calls to `round` when "copying" on-screen GDI rendering code), which is utterly unlikely. This is what I mean by "I should never have posted this question". There is not a problem with SVG, as I thought. So the question I originally believed was interesting, is in fact not even well-defined. To avoid confusion, I wrote my own answer explaining this.
Andreas Rejbrand
Your answer was not the solution, for you didn't say "You sample the function w/ a resolution of 0.0001 but then you round the coordinates to integers! Of course this cannot be magnified! You have just made a silly error in your code!". Instead you believed the issue was related to `polyline` - `path`, which it is not. `polyline` works perfectly now when I have removed the `round`s. Given this, it is rather immature to say that I "stole" your answer, and become pissed off because I did not award you the 250 points that I lost (and never saw again, of course). I want SO to be clear and compreh.
Andreas Rejbrand
To avoid the risk of misinterpretation: by "if you know anything" above, I mean "if one knows anything". In Swedish I would definitely have written "Om man vet något om..." rather than "Om du vet något om...".
Andreas Rejbrand
I have now voted to close this question, simply because it turned out to be a trivial (but far from common) bug in my code, and not at all an general issue with SVG.
Andreas Rejbrand
The FAQ states *When you have decided which answer is the most helpful to you, mark it as the accepted answer*. It does NOT say *When someone has debugged your code and resolved your issues, mark it as the accepted answer*.
Otaku
So now you believe that I have cheated to get all my rep? Thank you. I will now take 10 more mg of oxazepam. Then, please, I ask you to stay away from me. I am tired and not capable of handling more shit.
Andreas Rejbrand
You think I am a thief because I wrote my own answer to the actual question, but see http://stackoverflow.com/questions/2613337/getversionex-not-working-on-windows-7 .
Andreas Rejbrand
I am sorry if I have offended you in any way. But I have not, so please stop harassing me.
Andreas Rejbrand