3

I'm trying to implement the wmd-editor from the google code repository (like the one used on stackoverflow right here) and I'm running into an issue.

As you type into the textarea, it kicks off two paint operations in the browser. One to repaint the textarea itself, and one to repaint the preview panel. You can watch this happening on stackoverflow by opening the chrome inspector and using the timeline tab while typing some text into a question field.

But on my page, the browser repaints the entire viewport when it has to do these paint operations. And that takes much longer... about 100ms for each paint operation on my page versus about 1ms on stackoverflow.

In my testing this seems to be css related... I can recreate this behavior in the wmd-new example page by stripping all styles.

My page isn't public yet, but hopefully I can ask in a generic way... what will cause the browser to repaint the entire viewport on a dom change instead of just repainting that portion of the dom?

A view of what I'm talking about here. enter image description here

Bob Ralian
  • 1,949
  • 1
  • 20
  • 29
  • Are you seeing the in *all* browsers? Also, is there any transparency or shadowing happening in or around the editor? Anything with an opacity of <1 is always a huge slowdown. – balpha Feb 25 '11 at 07:12
  • Thanks balpha, your comment was spot-on. It was box-shadow on the body element. Disappointing, as it means I need to change my whole design just to accomodate this functionality. But really happy to have found the problem. I was going nuts trying to figure this out. – Bob Ralian Feb 25 '11 at 16:47

2 Answers2

6

AHA! Ah-effing-ha! (forgive the enthusiasm)

The issue is that I was using the box-shadow css property to frame my page. It takes longer to reflow/repaint content when the browser needs to calculate that shadow on each change (~100ms vs ~1ms). And when using wmd-editor, you're updating the dom on each keypress, so that difference adds up. And the effect is most exaggerated when the browser is maximized, as it recalculates the entire viewport.

So maybe that's one of the reasons stackoverflow doesn't have any frames or shadows on the page... just clean edges.

You can see what I mean at this example page. Open it up in firefox, maximized the page, and start typing away. Now use firebug to remove the box-shadow property on the body element, close firebug back up and try again. Big difference.

Thanks to Balpha for his comment, which was spot on.

Bob Ralian
  • 1,949
  • 1
  • 20
  • 29
  • 1
    Update: Took another look at that example link I gave and I no longer notice any lag in chrome or firefox. I think it's because browsers are just getting that much better. Cheers to the browser wars for pushing the web forward! – Bob Ralian Apr 03 '12 at 14:36
3

Check this presentation, around slide 70 and the next ones. They explain a bit what can cause reflow and repaint.

http://www.slideshare.net/nzakas/high-performance-javascript-webdirections-usa-2010

Without the specific code / CSS is hard to answer but I can say something general like, if the fragment DOM that was changed influences other elements in the page :)

Also note that in stackoverflow WMD, when you enter a newline it also causes a whole viewport repaint. So maybe it has something to do with your WYSIWYG area not having width and height well defined? I'm guessing that if you give them width and height they won't affect other elements in the page

AlfaTeK
  • 7,487
  • 14
  • 49
  • 90
  • Yeah, working on a stripped example that I can post. I don't think the presentation you posted quite gets at the issue, as this isn't an issue of many dom changes racking up many reflows. It's an issue of one dom injection taking longer than it should for its reflow. – Bob Ralian Feb 24 '11 at 22:52