Just wanted to add my thanks for this extension! Good job!
On Nov 21 2009, 4:46 pm, edwin bradford <i...@edwinbradford.net> wrote: > 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 > >extensioncalled 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 theextensionjdic-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 > > theextensionhere:http://cloud.github.com/downloads/tumult/jdic-chrome/jdic-chrome-buil... > > [13.5mb] > > > Please note that I do not knowJapanese, 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 thedictionarydata. 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 > >dictionaryin 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=en.
