[Libreoffice-commits] core.git: 2 commits - officecfg/registry svtools/source

[Zolnai Tamás]

 officecfg/registry/schema/org/openoffice/Office/Common.xcs |    2 +-
 svtools/source/graphic/grfmgr2.cxx                         |   10 +++-------
 2 files changed, 4 insertions(+), 8 deletions(-)

New commits:
commit 56020e09569ce078c108576b24efb66735cfc7c4
Author: Zolnai Tamás <tamas.zolnai at collabora.com>
Date:   Tue Nov 18 17:09:06 2014 +0100

    Be precise here, maximum value means it is still allowed to have
    
    Change-Id: I90c559c59b307aac6f7adac49ea38b0d9b68ad58

diff --git a/svtools/source/graphic/grfmgr2.cxx b/svtools/source/graphic/grfmgr2.cxx
index 19ab956..3b6a738 100644
--- a/svtools/source/graphic/grfmgr2.cxx
+++ b/svtools/source/graphic/grfmgr2.cxx
@@ -210,7 +210,7 @@ void GraphicManager::ImplCheckSizeOfSwappedInGraphics(const GraphicObject* pGrap
     // calc max allowed cache size
     const sal_uLong nMaxCacheSize(::std::min(GetMaxCacheSize(), aMaxSize32Bit));
 
-    if(mnUsedSize >= nMaxCacheSize)
+    if(mnUsedSize > nMaxCacheSize)
     {
         // Copy the object list for now, because maObjList can change in the meantime unexpectedly.
         std::vector< GraphicObject* > aCandidates(maObjList.begin(), maObjList.end());
commit dbdacc73ae154237314d599194cc686bd738a9bf
Author: Zolnai Tamás <tamas.zolnai at collabora.com>
Date:   Tue Nov 18 17:37:53 2014 +0100

    Be honest about the maximum cache size
    
    Implementation uses a multiplicator of ten. I guess the intention
    here was that to calculate cache size based on the size of the inserted
    images and not based on the real memory usage (potentionally more
    instances of one image), which seems a bad idea because it covers the
    real memory usage from the users (who will be suprised when LO's memory
    usage increases tenfold of the set value).
    
    It seems better to use the exact value in the implementation and increase
    the default value on the user interface instead.
    
    Change-Id: Ie3c0568d3518922d3a9931f894eebb9e7e5515ed

diff --git a/officecfg/registry/schema/org/openoffice/Office/Common.xcs b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
index e19df23..fec8d25 100644
--- a/officecfg/registry/schema/org/openoffice/Office/Common.xcs
+++ b/officecfg/registry/schema/org/openoffice/Office/Common.xcs
@@ -1466,7 +1466,7 @@
             objects.</desc>
             <label>Total Graphic Cache Size</label>
           </info>
-          <value>22000000</value>
+          <value>220000000</value>
         </prop>
         <prop oor:name="ObjectCacheSize" oor:type="xs:int" oor:nillable="false">
           <info>
diff --git a/svtools/source/graphic/grfmgr2.cxx b/svtools/source/graphic/grfmgr2.cxx
index 2ff6192..19ab956 100644
--- a/svtools/source/graphic/grfmgr2.cxx
+++ b/svtools/source/graphic/grfmgr2.cxx
@@ -200,11 +200,7 @@ namespace
 void GraphicManager::ImplCheckSizeOfSwappedInGraphics(const GraphicObject* pGraphicToIgnore)
 {
     // detect maximum allowed memory footprint. Use the user-settings of MaxCacheSize (defaulted
-    // to 20MB) and add a decent multiplicator (experimented to find one). Limit to
-    // a useful maximum for 32Bit address space
-
-    // default is 20MB, so allow 200MB initially
-    static sal_uLong aMultiplicator(10);
+    // to 200MB). Limit to a useful maximum for 32Bit address space
 
     // max at 500MB; I experimented with 800 for debug and 750 for non-debug settings (pics start
     // missing when office reaches a mem footprint of 1.5GB) but some secure left over space for
@@ -212,7 +208,7 @@ void GraphicManager::ImplCheckSizeOfSwappedInGraphics(const GraphicObject* pGrap
     static sal_uLong aMaxSize32Bit(500 * 1024 * 1024);
 
     // calc max allowed cache size
-    const sal_uLong nMaxCacheSize(::std::min(GetMaxCacheSize() * aMultiplicator, aMaxSize32Bit));
+    const sal_uLong nMaxCacheSize(::std::min(GetMaxCacheSize(), aMaxSize32Bit));
 
     if(mnUsedSize >= nMaxCacheSize)
     {