1135316 - Add features to the Necko cache so that we can eliminate any separate image cache

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Seth Fowler [:seth] [:s2h]]

The high level idea here is that we want to have a generic in-memory HTTP cache, instead of a special image-specific cache. We also want to get rid of nonsense like imgCacheValidator and imgRequestProxy::ChangeOwner, which are the source of many bugs and have caused problems when implementing security features.

There are two points in the design space that are worth exploring here, I think:

1. We can make it possible to associate Necko cache entries with an in-memory ref-counted object. We'd then be able to associate imgRequest objects with Necko cache entries. We'd always attempt a load, and if the load came from the cache, then we'd use a new Necko API to retrieve the associated imgRequest instead of constructing a new one.

2. We just completely drop the imgRequest objects, and reconstruct them when they get reloaded from Necko's cache. Since we discard the decoded versions of images when their associated tab or page gets closed, it's not actually clear how much benefit we get from keeping around the imgRequest. (We have to decode again no matter what.) However, we still want to share decode data from different requests for the same imgRequest that's still live somewhere, which probably means we do need something cache-like off to the side. It'd be simpler than the existing image cache, though - just a table of weak pointers.

Both of these solutions presuppose that we are also going to reenable the Necko in-memory HTTP cache and give the memory we used to use for the ImageLib image cache to it.