Wikimedia Bugzilla is closed!

Created attachment 2322 [details]
Patch to enable dvipng

My tests indicate a speedup on the order of a factor 3.

I don't have a MediaWiki server to try it on, nor any real knowledge of
ocaml, so I wrote a small python snippet that re-rendered the same image
again and again, using the os.system() call.

Based on other experience, I expected something like two orders of
magnitude more, but here, the repetitive call to dvipng on a one-page
DVI makes for an overhead in startup time. Example:

100 one-page DVIs, one image per DVI, dvips->convert: 120 s
100 one-page DVIs, one image per DVI, dvipng:         39 s, a factor 3

(my machine, YMMV)


If one is willing to put in some more work instead of my simpleminded
patch there is more to gain, say if one were to collect math into larger
DVI files:

100-page DVI, one image per page,     dvipng:        0.5 s, a factor 240

This collection of images is perhaps not desirable in MediaWiki. But it
is also entirely possible to run dvipng in deamon mode, telling it which
DVI to render and the desired output file...

100 one-page DVIs, one image per DVI, deamon dvipng:  1 s, a factor 120

That would of course increase with the number of DVIs you render. The
startup/shutdown of the program is 0.4 s, so each DVI rendered is
0.6/100=0.006 s. Compare that to the 1.2 s via the dvips->convert route.
If startup is done _once_ and all images rendered with an already
running dvipng, the factor is 200. This would involve having a dvipng
process running indefinitely on the server, but makes for interesting
prospects, no?

Email me if there are any questions. I don't know much about ocaml but I do know
the innards of dvipng.

By default, any modifications or comments to this bug will e-mail you (you can
change that in your preferences).

Jan-Åke,

I see you're the author of dvipng itself - could have told about that. :)

Anyway, right now dvipng is on our FC4 boxes, but not on FC3, which still are considerable majority. I tried backporting whole tetex package, but it is too big for manual fixes. 

What is the status of dvipng on sourceforge? How is it related to tetex?

OK, I see that tetex package has 1.5 release of dvipng. I'll probably roll our own RPM for FC3 boxes. 

Is it worth to have 1.8 release for FC4 too?

The devel takes place on savannah.nongnu.org, but you can download from
SourceForge too. dvipng is included in tetex-3 (and TeXlive and MIKTeX, but I
don't know what version you'll need, any recent would do). There are dvipng rpms
floating around, but only old ones.

You can download, build and install the source distribution in any UNIX  with a
proper build environment. Installing dvipng should be simple: merely
./configure, make, and make install. Otherwise, see
http://www.nongnu.org/dvipng/dvipng_2.html#SEC2

It would probably not be difficult to write a .spec file, but I haven't got a
RedHat machine at the moment to try it on. 

You absolutely want 1.8 on both machines, and you want it to link to a recent
FreeType. You see, the output quality is improved if you do that, otherwise
horizontal lines (as in "=") may be spread over two pixel rows, resulting in
blurry output.

I built http://dammit.lt/tech/packages/

Probably I'll want versioned binaries. *shrug*, this package should get conflicts on our FC4 boxes...

That was fast. There'll probably be conflicts, unless you manage to put the
binary in a path component that precedes the tetex path.

If/when you have questions about how to use daemon mode, just ask.

dvipng 1.8 deployed on site, patch above committed into trunk, wikimedia RPMs for both dvipng and texvc can be found at http://dammit.lt/tech/packages/