Hello. Recently, a friend of mine moved to Japan, and he was complaining about Firefox's sluggishness relative to WebKit-based browsers. He could not switch to Chrome because he frequently used the extension called rikaichan for Firefox, so I offered to recreate it for him on Chrome/Chromium. I made it specifically for him, but I'm sharing it in case anyone else is interested.
I named the extension jdic-chrome, and created a repository on GitHub: http://github.com/tumult/jdic-chrome Screenshot: http://files.chip.vg/jdic-chrome-screenshot.png You can download a packed (.crx) version of the extension here: http://cloud.github.com/downloads/tumult/jdic-chrome/jdic-chrome-build.crx [13.5mb] Please note that I do not know Japanese, so I cannot offer any help on any requests that require knowledge of the language. I may not update this file regularly, so in the future you might want to download it from source or check the GitHub repository for updates. It currently lacks many features other people may find useful. You can see the list of problems on the GitHub repository. The only interesting technical problem currently faced is the very high memory usage of the dictionary data. It exists as a very large set of JSON objects, preprocessed from the EDICT file format. Once loaded, the size bloats by about 10x. It appears to be outrunning the garbage collector. Forcing garbage collection (via opening the inspector and connecting the V8 debugger) reduces it by half, but it still remains around 130mb. Loading the data as JSON parsing on XHR requests was worse than including .js files with the objects in them, both in terms of loading speed and memory usage. I considered creating a separate index and holding the contents of the dictionary in memory as a large string, but I was more concerned with CPU usage than saving 50mb. If I had more inclination to work on that problem, it might have been worth profiling to see the difference in terms of lookup speed. With the current method, the cursor can be tracked and words can be looked up at ~50ms intervals with a minimal CPU hit (on the background page which is actually doing the lookups, that is. The animated bubble and DOM selection setting uses a fair bit on the client pages.) Another solution would be to use NPAPI and do it in a much more efficiently in a plugin, but I wanted to try something quite goofy and fun with JavaScript, and it ended up working out ok. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to chromium-extensions@googlegroups.com To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---