[Libreoffice-commits] core.git: Branch 'feature/gtkbmptiledviewer' - 2 commits - desktop/source include/basebmp

[Andrzej Hunt]

 desktop/source/lib/init.cxx             |   17 -----------------
 include/basebmp/rgbmaskpixelformats.hxx |   10 ++++++++++
 2 files changed, 10 insertions(+), 17 deletions(-)

New commits:
commit cd2b3d50447efe38bf3a7dae14079c2b48549c12
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Tue Jun 10 17:15:49 2014 +0100

    Add base value to set alpha channel for 32 bit colourspaces.
    
    Currently the alpha channel is completely ignored by basebmp.
    However this results in completely "transparent" output, meaning
    the client has to manually overwrite the alpha channel -- instead
    we now set it automatically when writing colourdata.
    
    Unfortunately this doesn't quite work -- it seems that drawing
    a non-opaque bitmap/image on top of the existing bitmap can
    erase the alpha channel information (i.e. these areas will
    once again be transparent -- for example document borders seem
    to have a transition effect overlayed onto them): presumably
    there is some method that bypasses our RGBMaskSetter (probably
    some form of direct manipulation of raw values?).
    manipulation in basebmp
    
    Change-Id: Ia4be6a748cc30191a4422121f9ec347d9198b225

diff --git a/include/basebmp/rgbmaskpixelformats.hxx b/include/basebmp/rgbmaskpixelformats.hxx
index d1d9b84..696f35a 100644
--- a/include/basebmp/rgbmaskpixelformats.hxx
+++ b/include/basebmp/rgbmaskpixelformats.hxx
@@ -148,6 +148,7 @@ template< typename     PixelType,
 
 template< typename     PixelType,
           typename     ColorType,
+          unsigned int BaseValue,
           unsigned int RedMask,
           unsigned int GreenMask,
           unsigned int BlueMask,
@@ -174,6 +175,7 @@ template< typename     PixelType,
         const typename base_type::unsigned_pixel_type blue (c.getBlue());
 
         typename base_type::unsigned_pixel_type res(
+            BaseValue |
             (shiftLeft(red,
                        base_type::red_shift-8*
                        (signed)sizeof(typename base_type::component_type)+
@@ -194,6 +196,7 @@ template< typename     PixelType,
 
 
 template< typename     PixelType,
+          unsigned int BaseValue,
           unsigned int RedMask,
           unsigned int GreenMask,
           unsigned int BlueMask,
@@ -209,6 +212,7 @@ template< typename     PixelType,
                           SwapBytes>            getter_type;
     typedef RGBMaskSetter<pixel_type,
                           Color,
+                          BaseValue,
                           RedMask,
                           GreenMask,
                           BlueMask,
@@ -256,6 +260,7 @@ template< typename     PixelType,
 // 16bpp MSB RGB
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt16,
+    0,
     0xF800,
     0x07E0,
     0x001F,
@@ -266,6 +271,7 @@ BASEBMP_SPECIALIZE_ACCESSORTRAITS(PixelFormatTraits_RGB16_565_MSB::getter_type,
 // 16bpp LSB RGB
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt16,
+    0,
     0xF800,
     0x07E0,
     0x001F,
@@ -286,6 +292,7 @@ BASEBMP_SPECIALIZE_ACCESSORTRAITS(PixelFormatTraits_RGB16_565_LSB::getter_type,
 
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt32,
+    0xFF000000,
     0x00FF0000,
     0x0000FF00,
     0x000000FF,
@@ -297,6 +304,7 @@ BASEBMP_SPECIALIZE_ACCESSORTRAITS(PixelFormatTraits_BGRX32_8888::getter_type,
 
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt32,
+    0xFF000000,
     0x00FF0000,
     0x0000FF00,
     0x000000FF,
@@ -308,6 +316,7 @@ BASEBMP_SPECIALIZE_ACCESSORTRAITS(PixelFormatTraits_XRGB32_8888::getter_type,
 
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt32,
+    0x000000FF,
     0xFF000000,
     0x00FF0000,
     0x0000FF00,
@@ -317,6 +326,7 @@ BASEBMP_SPECIALIZE_ACCESSORTRAITS(PixelFormatTraits_XBGR32_8888::getter_type,
 
 typedef PixelFormatTraitsTemplate_RGBMask<
     sal_uInt32,
+    0x000000FF,
     0xFF000000,
     0x00FF0000,
     0x0000FF00,
commit 37a9f11e0894de9b2de0128034095c14aec5c3c6
Author: Andrzej Hunt <andrzej.hunt at collabora.com>
Date:   Sun May 25 18:30:00 2014 +0100

    Get rid of outdated comments.
    
    We can now set the colourspace as desired, and we return the rowstride too.
    
    Change-Id: Idf1e55a67b9e9ab58e82d7ed0be2813b682ec2ff

diff --git a/desktop/source/lib/init.cxx b/desktop/source/lib/init.cxx
index fcdc358..2905949 100644
--- a/desktop/source/lib/init.cxx
+++ b/desktop/source/lib/init.cxx
@@ -381,23 +381,6 @@ static void doc_setPart(LibreOfficeDocument* pThis, int nPart)
     (void) nPart;
 }
 
-// TODO: Not 100% sure about the bitmap buffer format yet -- it appears
-// to just be RGB, 8 bits per sample, and vertically mirrored compared
-// to what gtk expects.
-// The BitmapDevice actually supports various formats, as detailed in
-// basebmp/scanlineformat.hxx -- for svp SVP_DEFAULT_BITMAP_FORMAT is seemingly used
-// (see creation in svpvd.cxx) -- which is simply FORMAT_TWENTYFOUR_BIT_TC_MASK
-// for now -- we could probably adjust this as necessary to get whatever
-// format is presumably most useful, or maybe even allow that as a parameter.
-//
-// It's actually possible to set the depth in the creation of a VirtualDevice,
-// however that only allows 0, 1 or 8 -- and we can't select the full range of formats
-// as above, so we'd need to add a way of setting the format entirely from scratch
-// should that be deemed necessary.
-//
-// We probably also want to use getScanlineStride() -- I'm guessing that
-// this is where we are actually just returning a sub-portion of a larger buffer
-// which /shouldn't/ apply in our case, but better to be safe here.
 static void doc_paintTile (LibreOfficeDocument* pThis,
                            unsigned char* pBuffer,
                            const int nCanvasWidth, const int nCanvasHeight,