In article <[EMAIL PROTECTED]>, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
> Henri Sivonen wrote: > > Is there a stable API that exposes the same data as getComputedStyle but > > without converting the style system data to strings? > > No. What would the interface actually output? I was thinking of using an enum as the style property input and enumerations as output for stuff like display and floats (in twips or better yet, in CSS px) for lengths. > > The reason why I am looking at nsIFrame is to avoid the overhead of going > > via string > > representations of data that exists as numbers and enumerations. > > How significant is this overhead in your case, compared to the other things > going on? I don't know really. Walking the DOM should be pretty fast as it only touches nodes and does not create any. Unless, of course, queryInterface in XPCOM instantiates interface proxies at that point or something like that. Presumably, the JavaScript side is actually allocating wrapper object at this point, right? For reference, I timed Java code walking the DOM of the Web Apps 1.0 test case (without comment nodes) using the Xerces DOM and the walk took 7 milliseconds on average with warmed caches on dualcore 2GHz PowerMac G5. (If I have understood correctly, the Java case genuinely only involves pointer dereferencing without memory allocation during the walk.) Going with strings would involve allocation overhead, whereas nsIFrame returns pointers to structs that are already there, so that might make a notable difference, assuming that the DOM walk does not actually allocate memory. But even so, the difference in wall clock time could be negligible. But this is only speculation. I have no idea and I am not at all familiar with the actual overhead of XPCOM DOM access. > > For the purpose of what I am interested in for this feature, an element > > is rendered if its non-whitespace text content was visible (assuming > > different color and background) > > So something with "opacity:0" is not "rendered", right? According to my definition, not, but the heuristic may not need to care. > And a node that has > no > non-whitespace textnode descendants (eg a table of images) is not "rendered" > either? Well, not in any sense that is of interest to the heuristic. > Your definition of "rendered" does, more or less, have having an nsIFrame as > a prerequisite (SVG aside). Excellent -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
