I too would like to add my thanks for this. The lack of rikaichan and bookmark sync were the two tools stopping me from switching from Firefox to Chrome, I tried jdic-chrome and it worked straight away, I was delighted. Now that I know they're both in the pipeline I've switched from Firefox as I couldn't stand it any longer. However I had lots of problems with the beta channels of Chrome so had to revert to the stable release and it won't run jdic-chrome for now. Am I right in thinking that eventually Google Chrome will be updated and I can install jdic-chrome in the stable version? Sorry for asking such a simple question.
On Oct 9, 12:11 pm, Andrew Richards <tum...@gmail.com> wrote: > 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-buil... > [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-extensi...@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=.
