Hope I'm not too late to give my ideas on this.
On Saturday 11 July 2009, Mark wrote:
> > +unsigned long favicon_hash(char *str)
...
> > + /* hashed values - saves calculating them afresh every time */
> > + #define HHICON 0x7c98572e
> > + /* icon */
> > + #define HHSHORTCUTICON 0xfcbccdca
> > + /* shortcut icon */
> > + #define HHAPPLETOUCHICON 0x024c6ddd
> > + /* apple-touch-icon */
> > + #define HHIMAGEPNG 0x7382417c
...
> > + if ((type = (char *) xmlGetProp(node,
> > + (const xmlChar *) "type")) != NULL) {
> > + switch(favicon_hash(type)) {
> > + /* here we score highest for "image/type"
> > + * mime types, lower scores for "type/ico"
> > + * mime types, no score for no type */
> > + case HHIMAGEPNG:
> > + score += 5;
> > + break;
> > + case HHIMAGEGIF:
> > + score += 5;
> > + break;
> > + case HHIMAGEVNDMICROSOFTICON:
> > + score += 5;
> > + break;
I think that lookup tables would be clearer than the hashing here and easier
to maintain in future (e.g. adding new types), unless profiling has shown this
to be a bottleneck. For example
struct favicon_type_entry {
char type[40];
int score;
};
static const struct favicon_type_entry favicon_type_table[] = {
{"apple-touch-icon", 5},
{"application/icon", 5},
...
};
and then bsearch can be used to find an entry. We use this method in several
places in NetSurf, for example see element_table in box_construct.c
> > Index: render/favicon.h
> > +typedef enum {
> > + HHICON = 0x7c98572e,
> > + /* icon */
This seems a duplicate of the #defines in the .c.
James
--
James Bursa, NetSurf developer http://www.netsurf-browser.org/
