[Libreoffice-commits] core.git: vcl/quartz

Tor Lillqvist tml at collabora.com
Thu Apr 3 02:46:17 PDT 2014


 vcl/quartz/salbmp.cxx |    8 ++++++++
 1 file changed, 8 insertions(+)

New commits:
commit 0f6149593129c3d208f07d0d017dec0c71760778
Author: Tor Lillqvist <tml at collabora.com>
Date:   Thu Apr 3 12:37:59 2014 +0300

    Make it easier to catch code that assumes SalBitmaps are created pre-cleared
    
    In a DBG_UTIL build fill the maContextBuffer and maUserBuffer of a
    QuartzSalBitmap with an easily recognized pattern. Helps catch
    situations where by coincidence they appear pre-filled with zeros most
    of the time and almost everything usually looks fine.
    
    Or is the QuartzSalBitmap implementation wrong, and SalBitmaps
    *should* be created filled with zeros?
    
    Change-Id: Ib5207779f2a47b9b7e539d8646b4128fea0ec150

diff --git a/vcl/quartz/salbmp.cxx b/vcl/quartz/salbmp.cxx
index 5ecc507..973a675 100644
--- a/vcl/quartz/salbmp.cxx
+++ b/vcl/quartz/salbmp.cxx
@@ -211,6 +211,10 @@ bool QuartzSalBitmap::CreateContext()
         try
         {
             maContextBuffer.reset( new sal_uInt8[ mnHeight * nContextBytesPerRow ] );
+#ifdef DBG_UTIL
+            for (size_t i = 0; i < mnHeight * nContextBytesPerRow; i++)
+                maContextBuffer.get()[i] = (i & 0xFF);
+#endif
 
             if( !bSkipConversion )
                 ConvertBitmapData( mnWidth, mnHeight,
@@ -261,6 +265,10 @@ bool QuartzSalBitmap::AllocateUserData()
     {
         if( mnBytesPerRow )
             maUserBuffer.reset( new sal_uInt8[mnBytesPerRow * mnHeight] );
+#ifdef DBG_UTIL
+        for (size_t i = 0; i < mnBytesPerRow * mnHeight; i++)
+            maUserBuffer.get()[i] = (i & 0xFF);
+#endif
     }
     catch( const std::bad_alloc& )
     {


More information about the Libreoffice-commits mailing list