https://bugs.documentfoundation.org/show_bug.cgi?id=100442
Michael Meeks <michael.me...@collabora.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |47148
--- Comment #5 from Michael Meeks <michael.me...@collabora.com> ---
Interestingly the GraphicManager:
for(sal_uInt32 a(0); mnUsedSize >= nMaxCacheSize && a <
aCandidates.size(); a++)
{
// swap out until we have no more or the goal to use less than
nMaxCacheSize
// is reached
GraphicObject* pObj = aCandidates[a];
if( pObj == pGraphicToIgnore )
{
continue;
}
if (std::find(maObjList.begin(), maObjList.end(), pObj) ==
maObjList.end())
{
// object has been deleted when swapping out another one
continue;
}
// do not swap out when we have less than 16KB data objects
if(pObj->GetSizeBytes() >= (16 * 1024))
{
pObj->FireSwapOutRequest();
}
Looks like it could (potentially) loop infinitely - if we blew the cache size
with lots of small (ie. less than 16k) images ...
I wonder if this is what happens in this case (?).
Of course there is a nice N^2 in the loop there with the std::find and the
iteration - but can we -really- have -that- many images ? =)
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=47148
[Bug 47148] image caching / management is utterly shambolic
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
