In article <20131201222742.ga12...@parsifal.org.uk>, John-Mark Bell <j...@netsurf-browser.org> wrote:
> Cool. A couple of things concern me about this change: Yep, there's a few things I kept simple while I tested the validity of the approach. > 1) The presence of a bloom filter internal to libcss is leaked through > the API to the client. This doesn't permit us to change the libcss > implementation details without clients' knowledge. The css_bloom_* implementations being exposed in the header? > 2) Related to the above, the change to the css_select_style is a > backwards-incompatible API/ABI change. I'm not hugely concerned by that until we're actually thinking of hitting version 1. But yeah. > Is there any reason why: > a) the bloom details can't be hidden entirely within libcss? It's where it is because the client is currently responsible for generating the node bloom filters. > b) libcss can't generate the bloom for a node, rather than relying on the > client to do so, which is fragile if the bloom size is changed within > libcss and the client is built against old headers? > c) we can't extend the libcss selection callback table to permit libcss > to store information on a dom node? (The selection callback table is > versioned, so libcss will have to fall back to the old, slower, > behaviour if it's called from a client built against the old version) That works for me. At the moment, the way node bloom generation is implemented in NetSurf is super efficient. It makes a node's bloom by simply adding the parent's strings to the parent's bloom. That will still be possible with the selection callback system. Since I'm primarily interested in NetSurf's performance, I plan to experiment a bit more with improving that before I do anything significant to the client interface. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
