Re: Selection optimisation

In article <20131201222742.GA12187@parsifal.org.uk>,
John-Mark Bell <jmb@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/