vcl/quartz/salbmp.cxx | 8 ++++++++ 1 file changed, 8 insertions(+) New commits: commit 0f6149593129c3d208f07d0d017dec0c71760778 Author: Tor Lillqvist <t...@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& ) { _______________________________________________ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits