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. > 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? > 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? >From skimming the X render spec it does appear that it supports converting between different pixel formats. XCopyArea won't do it. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
