NPAPI removal means no DjVu documents in Firefox

[l1bo...@gmail.com]

DjVu documents used to be viewable within firefox using a very reliable NPAPI plugin. With the removal of the NPAPI support, this no longer works.

Although there have been worthy attempts to use HTML5 technologies (e.g. https://github.com/mateusz-matela/djvu-html5) to view DjVu files, the Firefox JavaScript engine is far too slow to decode and render DjVu files in a manner that makes browsing agreeable. In fact, on a modern machine, the JS version is far slower than the NPAPI viewer ever was, even when it ran on a 1999 Pentium 90 machine.

One cannot even say that the DjVu NPAPI plugin was flimsy. The Unix version was rock-solid, running out-of-process from inception, detecting and supporting the GLib loop and Xembed protocols. The Window was more traditional but also simple and rock-solid. While it is true that some aspects of NPAPI were obsolete, one could have modernized the API instead of simply eliminating the capability.

The decision to support Flash (and only Flash) is very shocking to me. You may argue that many more people are viewing Flash content than are browsing DjVu documents. But is that really the spirit of open-source software? I thought the idea was to enable people instead of leveraging monopoly power to decide for them which technologies they can use or not.

Anyway, I am very disappointed.

- Leon Bottou

[Ehsan Akhgari]

Hi Leon,

I'm sorry to hear about your experience viewing DjVu documents in
Firefox given our plans for removing NPAPI plugins. I'm really
interested to understand the details of the performance problems in our
JavaScript engine that currently prevent the djvu-html5 viewer from
being a fast and usable replacement for viewing these documents. I'd
appreciate if you can help me by providing some examples that would
allow me to analyze them to ensure that we can address the performance
issues on our side in order to improve this situation in the future.

The project page you linked to below has a link to a live demo which I
looked at, which was pretty slow in Firefox
(http://mateusz-matela.github.io/djvu-html5/demo.html). I spent a few
minutes looking into the underlying reason and filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1384970 about it. The good
news is that this page is slow due to a limitation of our JS engine that
we are already aware of and are actively working on addressing, so
hopefully in the next few months there should be some improvements here.

One thing I'm not sure of is whether the specific overhead I saw on that
page is affecting all other djvu-html5 content or if there are other
issues at play. Since I don't have a lot of experience using djvu-html5
for viewing DjVu documents, I would really appreciate if you can point
me to a few other common ways that people typically use it, so that I
can also test those to see if I can discover other performance issues
that we should be aware of and working on fixing.

Thanks for taking the time to provide invaluable feedback.

All the best,

Ehsan

> _______________________________________________
> dev-tech-plugins mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-plugins

[Ehsan Akhgari]

Hi Leon,


On 08/10/2017 03:48 PM, Leon Bottou wrote:
>
> Thank you for looking into this.
>
> Alas my hopes are low. There are many parts of the DjVu decoding
> process that require specific optimization:
> - the arithmetic decoding is called for every bit of the decoded
> message (there are lots of them.)
> - the wavelet transform is nonstandard and implemented with a mix of
> shifts and adds for low power platforms, with vector extensions on
> modern cpus.
> - the image scaling and blending code is not something you can do with
> your average opengl primitive. It's done all by hand, one pixel at a
> time. Again sse when necessary.
>
> Therefore is is very unlikely that the JS version will even compete in
> speed with the native version. Unless of course the critical parts pf
> the code are provided as native apis. Note that the baseline djview
> plugin (the unix version) is a completely out-of-process
> implementation (since before 2000, btw). The only thing the npapi
> plugin did was to shuffle data back and forth, call NPN_GetURL when
> necessary, and map the djview window into the proper area of the html
> rendering. But I have no idea how to do this in pure JS.

I was hoping that you would provide me with some samples that would
allow me to profile them so that I could try to see if I would spot any
performance issues in SpiderMonkey, our JavaScript engine which
DjVu-HTML5 suffers from. For the record, the performance issue I
discovered in the bug I linked to below has nothing to do with any of
the JS code that the application is running, it is a general performance
issue we have when JS applications access JS objects that come from
same-origin iframes (for example, if you load your code in an
about:blank iframe and access the JS objects from the loaded code inside
your main page, your application would suffer from the said performance
issue, but if you loaded the same code inside the main page itself
without any other modifications, the performance issue would suddenly
disappear!)

I suggest measuring the actual performance of the application as opposed
to guessing about where the bottlenecks may be -- you may end up with
quite surprising results.

At any rate, to answer the questions above, there is actually a very
performant facility to translate C/C++ applications to run inside the
browser: https://developer.mozilla.org/en-US/docs/WebAssembly. Have you
looked into that? That may be a good option for porting the processing
code from the NPAPI plugin to run inside the web browser. Of course,
WebAssembly doesn't provide the NPAPI plugin layer, but if the plugin
itself was structured in a way to separate the processing code from the
NPAPI layer, it may be feasible to compile the processing code to
WebAssembly and run that along side with some glue code written in JS.
That should allow you to squeeze the most performance out of the
processing parts of the application.

Hope this helps,
Ehsan

>
> On Thu, Jul 27, 2017 at 12:00 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
>
> Hi Leon,
>
> I'm sorry to hear about your experience viewing DjVu documents in
> Firefox given our plans for removing NPAPI plugins. I'm really
> interested to understand the details of the performance problems
> in our JavaScript engine that currently prevent the djvu-html5
> viewer from being a fast and usable replacement for viewing these
> documents. I'd appreciate if you can help me by providing some
> examples that would allow me to analyze them to ensure that we can
> address the performance issues on our side in order to improve
> this situation in the future.
>
> The project page you linked to below has a link to a live demo
> which I looked at, which was pretty slow in Firefox
> (http://mateusz-matela.github.io/djvu-html5/demo.html

> <http://mateusz-matela.github.io/djvu-html5/demo.html>). I spent a

> few minutes looking into the underlying reason and filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=1384970
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1384970> about it.
> The good news is that this page is slow due to a limitation of our
> JS engine that we are already aware of and are actively working on
> addressing, so hopefully in the next few months there should be
> some improvements here.
>
> One thing I'm not sure of is whether the specific overhead I saw
> on that page is affecting all other djvu-html5 content or if there
> are other issues at play. Since I don't have a lot of experience
> using djvu-html5 for viewing DjVu documents, I would really
> appreciate if you can point me to a few other common ways that
> people typically use it, so that I can also test those to see if I
> can discover other performance issues that we should be aware of
> and working on fixing.
>
> Thanks for taking the time to provide invaluable feedback.
>
> All the best,
>
> Ehsan
>
>
> On 07/25/2017 10:23 PM, l1bo...@gmail.com

> <mailto:l1bo...@gmail.com> wrote:
>
> DjVu documents used to be viewable within firefox using a very
> reliable NPAPI plugin. With the removal of the NPAPI support,
> this no longer works.
>
> Although there have been worthy attempts to use HTML5
> technologies (e.g.
> https://github.com/mateusz-matela/djvu-html5

> <https://github.com/mateusz-matela/djvu-html5>) to view DjVu

> files, the Firefox JavaScript engine is far too slow to decode
> and render DjVu files in a manner that makes browsing
> agreeable. In fact, on a modern machine, the JS version is far
> slower than the NPAPI viewer ever was, even when it ran on a
> 1999 Pentium 90 machine.
>
> One cannot even say that the DjVu NPAPI plugin was flimsy. The
> Unix version was rock-solid, running out-of-process from
> inception, detecting and supporting the GLib loop and Xembed
> protocols. The Window was more traditional but also simple and
> rock-solid. While it is true that some aspects of NPAPI were
> obsolete, one could have modernized the API instead of simply
> eliminating the capability.
>
> The decision to support Flash (and only Flash) is very
> shocking to me. You may argue that many more people are
> viewing Flash content than are browsing DjVu documents. But is
> that really the spirit of open-source software? I thought the
> idea was to enable people instead of leveraging monopoly power
> to decide for them which technologies they can use or not.
>
> Anyway, I am very disappointed.
>
> - Leon Bottou

> _______________________________________________
> dev-tech-plugins mailing list
> dev-tech...@lists.mozilla.org

> <mailto:dev-tech...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-tech-plugins
> <https://lists.mozilla.org/listinfo/dev-tech-plugins>
>
>
>
>