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.h...@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.h...@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, _______________________________________________ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits