search

kripken / j2k.js

Port of OpenJPEG, an open-source JPEG2000 codec, to JavaScript using Emscripten
BSD 2-Clause "Simplified" License
83 stars 15 forks source link

[Firefox] Rendering #6

Open Merg1255 opened 12 years ago

Merg1255 commented 12 years ago

Check these files: https://github.com/downloads/bitsgalore/jp2StructCheck/testImages.zip http://www.openjpeg.org/index.php?menu=samples Chrome takes some time to render the images, but it finally does. Firefox 10.0.2 continues to prompt about the script running.

Is there a way we could speed the rendering up by using more workers?

Thanks

kripken commented 12 years ago

Using workers is hard because the code we compiled isn't multithreaded.

Can you profile in Chrome to see why this is so slow? Maybe we can hand-optimize some functions.

Merg1255 commented 12 years ago

just tested with some files, and the time needed for rendering is quite big. actually, anything more tan 2-3 seconds would not do for a website.

But there's an interesting point: jpeg2000 allows someone to view "part" of a page, without downloading the whole file, like 100MB. Could we change the canvas function to ask for specific parts of the image?

thanks

kripken commented 12 years ago

What does the Chrome JS profiler say? Maybe most of the time is in one function that we can optimize.

If the OpenJPEG2000 implementation supports viewing part of a page, we should be able to support it in j2k.js

Merg1255 commented 12 years ago

i'm using firefox :) but i'll probably try to use the chrome profiler the following days to see about the functions.

kripken commented 12 years ago

There is also a profiler for Firefox,

https://github.com/bhackett1024/CodeInspector

but it is experimental and requires a debug build of Firefox. It does give more in-depth information than the Chrome profiler though.

kripken commented 12 years ago

Another option is to add some manual profiling printouts in the main OpenJPEG functions. Could be easy to find out what we need to optimize.

Merg1255 commented 12 years ago

will check it out soon I think. thanks!

Merg1255 commented 12 years ago

ok, the most intensive cpu function is the one that actually draws the pixels in the pixel area, but I guess this can be easily seen without a cpu profiler.

kripken commented 12 years ago

Which function is that?

Merg1255 commented 12 years ago

it's function " xhr.onreadystatechange = function(e) { ... } ". My example is basically your example file here with a quite big jp2 file: https://github.com/kripken/j2k.js/blob/master/examples/simple.html

kripken commented 12 years ago

I see. We would need more detailed profiling information, inside the compiled code, to know which functions are the slow ones there.

Merg1255 commented 12 years ago

yes :-)