[cairo] [PATCH 2/3] Support a different pixel format for HDC
LRN
lrn1986 at gmail.com
Tue Apr 7 16:08:43 PDT 2015
On 07.04.2015 22:53, LRN wrote:
> On 07.04.2015 22:42, Bryce Harrington wrote:
>> On Fri, Apr 03, 2015 at 09:14:49PM +0200, Uli Schlachter wrote:
>>> Am 26.03.2015 um 20:44 schrieb LRN:
>>>> On 11.03.2015 0:31, Bryce Harrington wrote:
>>>>> On Tue, Mar 10, 2015 at 05:52:07PM +0300, LRN wrote:
>>>>>>>
>>>>>>> Patch #1 is from cairo bugzilla, see the link you gave me in [1].
>>>>>>>
>>>>>>> Patch #2 (this patch) was used by Mozilla[2] back in 2010. They have [had?]
>>>>>>> internal copy of cairo to patch, so maybe they just haven't bothered with
>>>>>>> submitting it. Or maybe they did submit it to cairo bugzilla and it got lost
>>>>>>> there. Who knows? Either way, the patch is trivial enough, so i wouldn't
>>>>>>> worry about this one too much.
>>>>>>>
>>>>>>>
>>>>>>> [1] http://lists.cairographics.org/archives/cairo/2014-April/025148.html
>>>>>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=577200
>>>>>>>
>>>>>>
>>>>>> Any progress on this?
>>>>>>
>>>>>> The fallback surface-related crash was fixed in 0.14, so the patch labeled "Enlarge fallback surface" is no longer necessary. I would only need this patch ("Support a different pixel format for HDC") and at least one bit from "Adjust assertions and checks to handle more pixel formats".
>>>>>>
>>>>>> These patches are very small, the only prerequisite for being able to evaluate them is understanding of cairo and W32 API. I'd very much like to stop patching cairo and push Windows RGBA code into GTK.
>>>>>>
>>>>>
>>>>> Mind extracting whatever bits are still needed, into new patches?
>>>>> Please use git format-patch against cairo trunk for creating them.
>>>>>
>>>>
>>>> Here they are.
>>>>
>>>> Do i need to send each one as a separate email (not an as an attachment) as well?
>>>
>>> We talked about these patches a bit on IRC. I have no clue about win32, but LRN
>>> and Google managed to convince me that this might make sense. It would be great
>>> if this were covered by the test suite, but the cairo_win32_surface_create()
>>> function isn't covered either (the source code claims that this doesn't make
>>> sense and the existing *_dib() boilerplate is enough).
>>>
>>> So this has my +1, although I would prefer if someone with some actual clue
>>> about win32 would look over this and say that this API makes sense.
>>
>> But bigger question is why add a whole API for just setting format to a
>> particular value? Why not a generalized public API that takes format as
>> an input? In other words, merge the above two routines:
>>
>> +cairo_surface_t *
>> +cairo_win32_surface_create_with_format (HDC hdc, cairo_format_t format))
>>
>> And then we still have cairo_win32_surface_create() calling this, with
>> format=CAIRO_FORMAT_RGB24.
>
> That is also reasonable.
Attaching the new version of the patch. Since i'm not using the original
Mozilla patch verbatim anymore, i've squashed the second patch (the format
check in create_with_ddb()) into it and updated both, signoffing as myself. The
diff looks a bit strange though.
I've added a note to the documentation to clarify the meaning of the format
argument a bit.
One final test that i did is to mess up gtk in different ways and see what
comes up:
If GDK does not enable alpha channel use for a Window using
DwmEnableBlurBehindWindow(), then there's no transparency regardless of what
format is given to cairo when creating a surface for the window DC. Transpaency
is ignored by the window manager.
If GDK enables alpha channel, but tells cairo to use RGB24 format for the
window, cairo will internally use GDI for drawing, which will screw up the
alpha channel of the window in various unusual ways (usually, opaque black
pixels become transparent, etc).
If GDK enables alpha channel and tells cairo to use ARGB32 format, everything
is fine. Cairo uses internal (pixman) drawing routines to draw on the surface.
There's code to use the AlphaBlend API, but it partially disabled. I don't
remember what happens if it's enabled (i've tried that before). Because pixman
(not GDI) does the drawing, GDI can't screw up the alpha channel.
I've tried a few W32API functions on the HDC to see if i can detect
alpha-transparency on it, but came up short. Googling suggests that this is not
possible, and that this is a shortcoming of GDI as a whole (most of its
function will either screw up the alpha channel or leave it untouched).
--
O< ascii ribbon - stop html email! - www.asciiribbon.org
-------------- next part --------------
From c4e516afd6098fe2796b640024974bf015b1421d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
=?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= <lrn1986 at gmail.com>
Date: Thu, 26 Mar 2015 19:33:43 +0000
Subject: [PATCH 1/2] Add cairo API to set up a Win32 surface for an HDC with
an alpha channel.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Руслан Ижбулатов <lrn1986 at gmail.com>
---
src/cairo-win32.h | 4 ++
src/win32/cairo-win32-display-surface.c | 70 +++++++++++++++++++++++++--------
2 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/src/cairo-win32.h b/src/cairo-win32.h
index 3d2e1c6..db4cac6 100644
--- a/src/cairo-win32.h
+++ b/src/cairo-win32.h
@@ -49,6 +49,10 @@ cairo_public cairo_surface_t *
cairo_win32_surface_create (HDC hdc);
cairo_public cairo_surface_t *
+cairo_win32_surface_create_with_format (HDC hdc,
+ cairo_format_t format);
+
+cairo_public cairo_surface_t *
cairo_win32_printing_surface_create (HDC hdc);
cairo_public cairo_surface_t *
diff --git a/src/win32/cairo-win32-display-surface.c b/src/win32/cairo-win32-display-surface.c
index 965f2c4..51e216c 100644
--- a/src/win32/cairo-win32-display-surface.c
+++ b/src/win32/cairo-win32-display-surface.c
@@ -917,31 +917,41 @@ static const cairo_surface_backend_t cairo_win32_display_surface_backend = {
*/
/**
- * cairo_win32_surface_create:
+ * cairo_win32_surface_create_with_format:
* @hdc: the DC to create a surface for
+ * @format: format of pixels in the surface to create
*
* Creates a cairo surface that targets the given DC. The DC will be
* queried for its initial clip extents, and this will be used as the
- * size of the cairo surface. The resulting surface will always be of
- * format %CAIRO_FORMAT_RGB24; should you need another surface format,
- * you will need to create one through
- * cairo_win32_surface_create_with_dib().
+ * size of the cairo surface.
*
- * Return value: the newly created surface
+ * Supported formats are:
+ * %CAIRO_FORMAT_ARGB32
+ * %CAIRO_FORMAT_RGB24
*
- * Since: 1.0
+ * Note: @format only tells cairo how to draw on the surface, not what
+ * the format of the surface is. Namely, cairo does not (and cannot)
+ * check that @hdc actually supports alpha-transparency.
+ *
+ * Return value: the newly created surface, NULL on failure
+ *
+ * Since: 1.14.3
**/
-cairo_surface_t *
-cairo_win32_surface_create (HDC hdc)
+static cairo_surface_t *
+cairo_win32_surface_create_with_format (HDC hdc, cairo_format_t format)
{
cairo_win32_display_surface_t *surface;
- cairo_format_t format;
cairo_status_t status;
cairo_device_t *device;
- /* Assume that everything coming in as a HDC is RGB24 */
- format = CAIRO_FORMAT_RGB24;
+ switch (format) {
+ default:
+ return _cairo_surface_create_in_error (_cairo_error (CAIRO_STATUS_INVALID_FORMAT));
+ case CAIRO_FORMAT_ARGB32:
+ case CAIRO_FORMAT_RGB24:
+ break;
+ }
surface = malloc (sizeof (*surface));
if (surface == NULL)
@@ -977,6 +987,28 @@ cairo_win32_surface_create (HDC hdc)
}
/**
+ * cairo_win32_surface_create:
+ * @hdc: the DC to create a surface for
+ *
+ * Creates a cairo surface that targets the given DC. The DC will be
+ * queried for its initial clip extents, and this will be used as the
+ * size of the cairo surface. The resulting surface will always be of
+ * format %CAIRO_FORMAT_RGB24; should you need another surface format,
+ * you will need to create one through
+ * cairo_win32_surface_create_with_format() or
+ * cairo_win32_surface_create_with_dib().
+ *
+ * Return value: the newly created surface, NULL on failure
+ *
+ * Since: 1.0
+ **/
+cairo_surface_t *
+cairo_win32_surface_create (HDC hdc)
+{
+ return cairo_win32_surface_create_with_format (hdc, CAIRO_FORMAT_RGB24);
+}
+
+/**
* cairo_win32_surface_create_with_dib:
* @format: format of pixels in the surface to create
* @width: width of the surface, in pixels
@@ -1027,12 +1059,16 @@ cairo_win32_surface_create_with_ddb (HDC hdc,
HDC screen_dc, ddb_dc;
HBITMAP saved_dc_bitmap;
- if (format != CAIRO_FORMAT_RGB24)
+ switch (format) {
+ default:
+/* XXX handle these eventually */
+ CAIRO_FORMAT_A8:
+ CAIRO_FORMAT_A1:
return _cairo_surface_create_in_error (_cairo_error (CAIRO_STATUS_INVALID_FORMAT));
-/* XXX handle these eventually
- format != CAIRO_FORMAT_A8 ||
- format != CAIRO_FORMAT_A1)
-*/
+ case CAIRO_FORMAT_ARGB32:
+ case CAIRO_FORMAT_RGB24:
+ break;
+ }
if (!hdc) {
screen_dc = GetDC (NULL);
--
1.8.5.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x922360B0.asc
Type: application/pgp-keys
Size: 1717 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20150408/0bb6f2f8/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cairographics.org/archives/cairo/attachments/20150408/0bb6f2f8/attachment-0001.sig>
More information about the cairo
mailing list