As far as I see, the surfaces created in the DX canvas are of
D3DFMT_A8R8G8B8 or D3DFMT_X8R8G8B8 format, which means that the bytes
(in memory order, on little-endian Windows) are B,G,R,A/X. So if the
desired destination wants R,G,B,A, we need to swap the blue and red
bytes.
Let's hope this doesn't break anything else...
Change-Id: I1b90d2cf95418f6557cac633ec6fce27599e8a61
imgdbug.h ins included in canvs under some debugging flags
but that header comes from
http://billbaxter.com/projects/imdebug/
and is nowhere to be found in our source. the original project
has been dead for a long while.. the last 'news' was that it was
migrating to the now defunc 'berlios' hosting site.
Change-Id: Idd030164f4ef0b28973530df69323cb952e99169
Reviewed-on: https://gerrit.libreoffice.org/17655
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Again the ULONG clashes on 64-bit Windows cause pain. Work around by
using pre/postwin.h, and that then necessitates use of explict
WIN_BYTE instead of just BYTE. Sigh...
2008/06/03 23:52:24 thb 1.1.2.5: Removed extra level of indirection for getting a graphics for a surface; removed some unused code
2008/06/03 11:11:24 thb 1.1.2.4: Cleaned up image debugging stuff; fixed a few d3d debug warnings; fixed one deadlock rendering a bitmap from the same surface to itself; fixed premature ReleaseDC call in GraphicsProvider::getGraphics()
2008/05/23 22:03:45 thb 1.1.2.3: Moving all remaining new files to LGPL 3
2008/02/08 00:26:39 thb 1.1.2.2: #81092# Finishing cooperative canvas output stuff
2008/01/22 00:25:24 thb 1.1.2.1: #i81092# Making gdiplus and dx canvas more independent
