On Tue, Jul 23, 2013 at 11:34 PM, Peter Krautzberger < peter.krautzber...@mathjax.org> wrote: > > @Derk-Jan could you give some background on your "MathJax is a nightmare" > comment? Have their been specific reports or complaints? Or is this > something specific out of development (like the float issue)? It seems > MathJax is slower on Wikipedia than on other sites. Wikipedia's MathJax > configuration is definitely not optimal, and it seems the integration into > MediaWiki isn't either. I agree that the best first step is to replace the > PNGs on the fly -- that's almost trivial and has no risk attached. >
The float issue is irrelevant to this. 1: Wikipedia pages are complex. Thousands of nodes per page content and often rather deep, all of which needs to be considered for MathJax. 2: We have multiple scripts that need to look at 'a lot of nodes'. MathJax is not alone. 3: MathJax is simply complex. They are complex scripts, with a lot of computations. 4: Wikipedia pages are a complex canvas. Every finished mathjax rendering reflows the page. (which is a good idea actually in the case of MathJax, but probably taxing the system) 5: MathJax does not currently make use of our ResourceLoader, because it uses it's own scriptloaders. This however requires quite a few URL connections (one of RL's primary function is script request bundling). I'm not even sure if we can make it use ResourceLoader (the autostart of the main MathJax script might be problematic here....). Also keeping all file registrations in sync definitely would require a script or something to keep it maintainable. And last of all, we simply have a lot of people using the software for whom a few kilobytes of traffic might already be noticeable on their connections. The amount of complaints we in general get for adding Javascript is already considerable, and those scripts are magnitudes (factor 100x) smaller than MathJax, so i'm sure we would get a lot of negative response from parts of the community. There is definitely some room for improvement, but I doubt it will become magnitudes faster within a few years. DJ > ---------- Forwarded message ---------- > From: Max Semenik <maxsem.w...@gmail.com> > Date: Tue, Jul 23, 2013 at 8:38 AM > Subject: Re: [Wikitech-l] Long term strategy for math on wikipedia > To: Wikimedia developers <wikitech-l@lists.wikimedia.org> > > > On 23.07.2013, 19:30 C. wrote: > > > On Tue, Jul 23, 2013 at 5:20 AM, Derk-Jan Hartman < > > d.j.hartman+wmf...@gmail.com> wrote: > > >> So what I would actually propose for the short term (next few years) in > >> case we really want to go the direction of MathML is the following: > >> 1: img tag + --data-math=formulaID in HTML > >> 2: script to detect MathML support in browser > >> 3: script retrieves MathML DOM from API using formulaID > >> 4: script replaces img with MathML > >> > > > It's worth thinking about future-editor issues as well. Perhaps > rendering > > MathML client-side into a <canvas> is a better transition strategy -- it > > would lead to a more responsive editor than having to do a server call > > every character to update the render. > > > I haven't really looked into this -- are there any good javascript math > > renderers? (Compiling the TeX implementation in C into client-side > > JavaScript using emscripten might even be an option.) > > MathJax - the one we're using:) > > > > -- > Best regards, > Max Semenik ([[User:MaxSem]]) > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
