Re: Images in a Multiprocess World

I have no evidence to back this up but it does seem like sharing  
images across tabs is actually fairly frequent occurrence when the  
tabs are all from the same site.  FWIW my pattern for reading news is  
to open up a new tab for each interesting story, then close them as I  
read each one.   Maybe I'm an anomaly in that case.  Performance wise  
we might be damned if we do or damned if we don't.. pageload latency  
and network cost vs increased IPC overhead.  We'd also be responsible  
for a not-insignificant increase in server loads for most websites.   
It might also making scaling to many processes harder in the future  
due to memory consumption issues, unless we have a dynamic per-proc  
cache size limit?

I'm also wondering if there might be concerns about the same image  
being out of sync between tabs, but maybe there's really no guarantee  
of that anyway given cache performance is not very reliable from a web  
dev perspective.
   Lucas.

On Jun 23, 2009, at 9:43 AM, Benjamin Smedberg wrote:

> On 6/23/09 12:08 PM, Joe Drew wrote:
>>
>> On Jun 23, 2009, at 10:17 AM, Benjamin Smedberg wrote:
>>
>>> I would hope, though, that the network cache, which is planned to be
>>> shared,
>>> would take care of making sure we don't download images twice. Is  
>>> image
>>> decoding really an expensive-enough operation that we want to add  
>>> lots of
>>> extra machinery?
>>
>> We already have that extra machinery in the form of the image cache.
>> Decoding on its own isn't that expensive, but doing it over and  
>> over for
>> the same images sucks, and breaks some web consumers (see bug  
>> 466586).
>
> I believe that with multi-process we're unlikely to be using the  
> same image
> in multiple tabs, and we could just use a per-process image cache.  
> Are you
> saying there are web-compat issues where if we had a per-process  
> image cache
> backed by the necko HTTP cache we'd somehow cause problems for  
> websites?
>
> --BDS
> _______________________________________________
> dev-tech-dom mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-dom