Hi Andrew Can I just say Fantastic Extension! It is great for people like me that aren't too advanced with their japanese. 1 problem with the extension is that I cannot select text while the extension is enabled, can you look at getting this fixed?
Thanks 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-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 -~----------~----~----~----~------~----~------~--~---
