[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