Comments on: debugging painting with MozAfterPaint

By: lrbabe

lrbabe — Wed, 24 Jun 2009 19:47:46 +0000

@Wired Earp: Switching the visibility of the body and changing some classes of the DOM in the meantime is already possible without the user noticing it. And it is cross-browser : )

By: 颠覆网络35天 ─ 使用MozAfterPaint调试绘图 < MJiA

颠覆网络35天 ─ 使用MozAfterPaint调试绘图 < MJiA — Wed, 24 Jun 2009 02:44:59 +0000

[...] 原文地址：debugging painting with MozAfterPaint 系列地址：颠覆网络35天 [...]

By: Boris

Boris — Tue, 23 Jun 2009 23:53:36 +0000

Wired Earp, the problem with a setup like you propose is that authors would tend to forget to _enableRepaint().

On the other hand, if you’re just building DOM structures, there’s no repainting going on anyway, unless you take special pains to allow it (e.g. setTimeout to put off the rest of the work to later). So it’s not clear to me exactly what you’re asking for here.

By: Wired Earp

Wired Earp — Tue, 23 Jun 2009 09:05:35 +0000

Even more awesome would be a “MozBeforePaint” event that I could preventDefault (), maybe combined with a setup to trigger repaint on command. Maybe even something like:

window.__disableRepaint ();
// build DOM structures and change 1000 classNames…
window.__enableRepaint ();
window.__repaint ();

Question to the comment readers: Can anyone imagine a setup that would emulate this setup using chrome code? Haven’t found anything useful, maybe I just don’t know where to look.