On Thu, Feb 12, 2009 at 12:16 AM, Evan Martin <[email protected]> wrote:
> On Wed, Feb 11, 2009 at 11:54 PM, Darin Fisher <[email protected]> wrote: > >> Conceptually a given renderer needs one of these per paint operation, > >> but it seems each renderer process keeps a simple cache of the last > >> two shared memory regions used (I assume to prevent needing to rapidly > >> set up these regions repeatedly?). I wonder, how expensive is it to > >> allocate shared memory? > > > > we found it to be surprisingly expensive in this context. perhaps it is > a > > property of the windows VM, but if we allocate, memcpy, free the virtual > > memory for the transport DIB, we seem to make a lot more work for > windows. > > if instead use the small recycling cache, windows is far happier. "the > > transport DIB stays hot, which keeps the memcpy cheap" :) > > Ah, I meant my question the other way around: is a two-entry cache > enough? It seems it could be decently expensive to recreate these > sections even with the cache in place. > Usually there is only one tab animating at a time ;-) The other key element to our painting architecture is that the renderer does not paint again until the transport DIB is flushed to the screen. This is done to ensure that the renderer is not doing excessive work (generating extra frames) that would just be thrown away. We do allow the renderer to pre-render the next frame so that we get some overlapped processing (good on multi-core systems), but we don't allow it to do any more overlapping work than that. So, 2 transport DIBs seemed OK. It should probably be tuned based on histograms :) We could easily build a more adaptive cache. > > > CreateCompatibleBitmap creates a DDB, which is taxed against the memory > > limits of the desktop. the desktop has a very small address space, so > DDBs > > should only be used as temporary scratch space by applications. you can > > really screw over your windows box if you allocate a number of large DDBs > > :-( > > Is the situation comparable to X pixmaps, or are there extra limits on > the desktop address space? I don't know... I would imagine that the X server allows you to allocate a lot of pixmaps. Hopefully the limit is based on the available virtual memory on the X server. The default limit for the windows desktop is depressingly low: 48 MB. http://msdn.microsoft.com/en-us/library/ms682124(VS.85).aspx "The number of desktops that can be created is limited by the size of the system desktop heap, which is 48 MB. Desktop objects use the heap to store resources." It turns out that DDBs are allocated against that limit! > > > > agl suggested using shared memory for the transport DIB that is > compatible > > with the X server. that means MIT-SHM instead of posix shared memory > (see > > base/shared_memory). we should be able to blt from this ARGB surface > onto > > the device-dependent backingstore. i guess that might require something > > like Xrender. > > To be clear, you're saying that the transport DIB could be shared with > the X server, but that it must remain ARGB for compatibility with the > WebKit/Skia drawing, right? Right > > > From skimming the X render spec it does appear that it supports > converting between different pixel formats. XCopyArea won't do it. > OK We can probably count on X render being available, right? -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
