[Webkit-unassigned] [Bug 103175] Make renderer construction less generic

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=103175





--- Comment #5 from Ojan Vafai <ojan at chromium.org>  2012-11-24 09:57:37 PST ---
(In reply to comment #4)
> It is not simpler as such. The goal is to tighten the code so that it statically describes what is possible and what is not. 

Even without these goals, I think tighening up the code is a big win. I really like the direction of this change. 

I cringe a little at the code duplication between createRendererForElementIfNeeded and createRendererForTextIfNeeded. I think you could get rid of much of it by adding a couple static helper functions?

> Beyond the architectural improvement, the end goals include
> 
> - Make it go faster. The current code is unnecessarily branchy because it is overly generic.
> - Use lazy attach during parsing to reduce unnecessary style recalcs. To do this efficiently we need to change the renderer construction in ways that benefit from reduced genericity.
> - Get rid of the Text nodes in common case. We should synthesize them on DOM access only. This requires separating the text construction path.

These are great goals! I wonder with the latter goal if we could even take it a step further and get rid of the C++ side object entirely and just have the javascript wrapper. Obviously, this would be a followup step. The big difficulty with this would be dealing with editing/selections since those can be inside Text nodes. Maybe we could have a lighter-weight thing inside editing/selection to handle text without actually creating the Nodes, but that sounds tricky.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.