On Fri, Sep 11, 2009 at 1:35 PM, Jason Grout <[email protected]> wrote: > > William Stein wrote: >> On Fri, Sep 11, 2009 at 11:20 AM, Tom Boothby <[email protected]> >> wrote: >>> On Fri, Sep 11, 2009 at 11:14 AM, Jan Groenewald <[email protected]> wrote: >>>> Hi >>>> >>>> On Fri, Sep 11, 2009 at 12:36:00PM -0500, Jason Grout wrote: >>>>> I'm just throwing it out there in the >>>>> interest of brainstorming. >>>> Two more ideas: >>>> >>>> 1. a by default OFF feature, which can somewhere be set to >>>> on, to prevent the CPU/RAM problems. Probably will trip up >>>> inexperienced users who will leave it on though. >>> The aforementioned CPU/RAM problems are intractable in the multi-cell >>> mode. Having more than three or four syntax-highlighting franken-divs >>> will just crash your browser. Perhaps if you have a few dozen gigs of >>> RAM, it won't crash because it will slow to a crawl before filling up >>> all available memory. >> >> That is a bit of an exageration, but a fun one :-) > > > Indeed! I just opened up 6 TinyMCE instances (which are exactly these > "franken-divs" that we are talking about), and things seemed pretty > snappy still. There was a CPU spike when the TinyMCE initialized, but > input seemed very responsive. Keep in mind that only one of these > content-editable divs will be changing at a time.
MCE is not the problem -- the one I'm referring to (the name escapes me at the moment) was a full-blown code editor -- it had syntax highlighting as you go, a custom undo buffer, the works. And it blew up any browser that I tried it on if you have more than a couple of them on screen -- even if the actual editor part was backgrounded. > Why would having more than one content-editable div increase the memory > that much? Presumably there is a global shared library of javascript > functions that provide all the actual guts of the editing, so there > won't be that much memory needed to instantiate any single editor. You'd think so... but keep in mind that a syntax-highlighting frankendiv works by putting every word in a separate DOM object. The result is exceptionally massive DOM trees that quickly fill all available memory. Now add to that jsMath and jQuery which frequently walk the entire DOM tree, often running regular expressions on the contents -- this takes up all available processor time. This *could* be done right with the tools that are available to us (the javascript-using community), but it hasn't been done right yet, and I do not believe that there are easy drop-in solutions (we're not inventing the wheel, right?) for this yet. I'm hoping that BeSpin will be the silver bullet. > > Jason > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
