<<O>>  Difference Topic FaviconCache (r1.3 - 29 Jan 2005 - CrispinFlowerday)
Line: 1 to 1
Changed:
<
<
META TOPICINFO TommiKomulainen date="1104780770" format="1.0" version="1.2"

PLAN:

>
>
META TOPICINFO CrispinFlowerday date="1107009392" format="1.0" version="1.3"

PLAN (Done):


Changed:
<
<
Improve the favicon cache. It has a variety of problems at the moment:
>
>
Improve the favicon cache.

DONE This has been done using tko's method below.

It has a variety of problems at the moment:


  • It gets huge
  • Which means it takes ages to read in
Line: 10 to 14

In theory we only need to store images on disk for favicons that are needed not as a result of a page load. This means that just bookmarks (for the moment, history doesn't use them at the moment) will need them stored on disk.

Added:
>
>


What I propose is:

  • Make the favicon-cache only load images on-demand rather than on startup
Line: 38 to 44

To download icons, we should use something like tko's code in http://bugzilla.gnome.org/show_bug.cgi?id=131865 although we need to check to see whether that uses the mozilla cache.

Added:
>
>
-- CrispinFlowerday - Dec 2004


Sounds little backwards (the GaleonFaviconUser thingie.) Braindumping here.


 <<O>>  Difference Topic FaviconCache (r1.2 - 03 Jan 2005 - TommiKomulainen)
Line: 1 to 1
Changed:
<
<
META TOPICINFO CrispinFlowerday date="1104689423" format="1.0" version="1.1"
>
>
META TOPICINFO TommiKomulainen date="1104780770" format="1.0" version="1.2"

PLAN:

Improve the favicon cache. It has a variety of problems at the moment:

Line: 38 to 38

To download icons, we should use something like tko's code in http://bugzilla.gnome.org/show_bug.cgi?id=131865 although we need to check to see whether that uses the mozilla cache.

Added:
>
>

Sounds little backwards (the GaleonFaviconUser thingie.) Braindumping here.

Two kinds of favicons:

  1. Persistent.
    • used for bookmarks
    • backed up by a local copy
    • need to maintain page URL --> favicon URL --> local file mapping (the latter part could be implicit)
    • local copy is updated (and old one discarded) whenever the page URL --> favicon URL mapping, or the favicon itself, changes
    • local copy is removed when the (last) bookmark is removed
  2. Transient.
    • used everywhere else, location entry, tab labels, Go menu, ...
    • use browser cache for storage

The GaleonFaviconCache API could be something like:

GaleonFavicon *galeon_favicon_cache_get            (self, const char *page_url);
void           galeon_favicon_cache_set_url        (self, const char *page_url, const char *favicon_url);
void           galeon_favicon_cache_set_persistent (self, const char *page_url, gboolean    is_persistent);

Internally the favicon cache can maintain a "page URL" --> GaleonFavicon mapping, whenever favicon changes all "subscribed" images are updated. We could also keep a favicon URL --> GdkPixbuf mapping in memory to avoid loading the same favicon multiple times. (Slight speed increase, saves some memory.)

Since the GaleonFaviconCache is providing GaleonFavicon rather than GdkPixbuf we can load the pixbuf contents asynchronously whenever. If a pixbuf is already in memory we can use it immediately. Otherwise we'll load the favicon from local file or cache only. We will not try to load anything from the network when the galeon_favicon_cache_get() is called.

Only when (during loading the page) the galeon_favicon_cache_set_url() is called (and there is someone "subscribed" to the page URL) we will attempt loading the favicon from remote server in addition to local copy and browser cache. If the page URL was flagged persistent, the local copy should be updated, otherwise the favicon should be loaded directly into a GdkPixbuf, no need for extra files (need to extend GaleonEmbedPersist a little, I guess.) Once the pixbuf has finished loading we'll just iterate through the "subscribers" for the page URL and update the =GaleonFavicon=s with the new pixbuf.

The page URL --> favicon URL mapping and the favicon contents need to be saved on the disk only for persistent favicons, i.e. bookmarks.

-- TommiKomulainen - 03 Jan 2005


 <<O>>  Difference Topic FaviconCache (r1.1 - 02 Jan 2005 - CrispinFlowerday)
Line: 1 to 1
Added:
>
>
META TOPICINFO CrispinFlowerday date="1104689423" format="1.0" version="1.1"

PLAN:

Improve the favicon cache. It has a variety of problems at the moment:

  • It gets huge
  • Which means it takes ages to read in
  • It is not a 'cache'
  • It stores images on disk, which don't need to be there.

In theory we only need to store images on disk for favicons that are needed not as a result of a page load. This means that just bookmarks (for the moment, history doesn't use them at the moment) will need them stored on disk.

What I propose is:

  • Make the favicon-cache only load images on-demand rather than on startup
  • Add an interface to the bookmarks GaleonFaviconUser that is registered with the favicon cache so it can query whether the bookmark code needs a particular url (and hence favicon).
  • Make the favicon cache query GaleonFaviconUser objects when it is saving to disk, so that it only saves favicons that are actually needed
  • It will use the mozilla cache to read favicons, so it is possible that mozilla will cache the most commonly used non-bookmark favicons

When a page is loaded that has a favicon:

  • The favicon cache is told (like it is at the moment) the url of the page and favicon
  • If the url and favicon are the same as previously stored, then it returns.
  • It remembers the url and favicon url, but does not download it yet
  • It emits the "changed" signal

When an object wants a favicon

  • It asks the favicon cache for the icon for a url
  • the favicon cache looks up the url, and sees if it has the icon stored (or a path for it)
  • if it does, it reads it off disk if need be
  • otherwise it uses the stored url, and starts an embed_persist object to download it
  • the caller is told that the image is not there
  • the caller must also listen on the "changed" signal of the cache
  • when the icon is downloaded the "changed" signal is emitted
  • the object then re-looks up the favicon and now it is there

Peridocally, the favicon cache will cull the GdkPixbuf?'s from memory that haven't been used in a while, it will also save images that are used for bookmarks to disk.

To download icons, we should use something like tko's code in http://bugzilla.gnome.org/show_bug.cgi?id=131865 although we need to check to see whether that uses the mozilla cache.


Revision r1.1 - 02 Jan 2005 - 18:10 - CrispinFlowerday
Revision r1.3 - 29 Jan 2005 - 14:36 - CrispinFlowerday
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Galeon? Send feedback.