[cairo] win32 backend failure with Cairo 1.0.4

[Mikael Claesson]

--- Carl Worth <cworth at cworth.org> wrote:

> On Mon, 19 Jun 2006 03:04:37 -0700 (PDT), Mikael
> Claesson wrote:
> >
> > The Cairo 1.0.4 win32 backend fails when the
> screen
> > has a depth of 16 bpp. There is a test in
> > cairo_win32_surface_create() which selects a
> > cairo_format_t based on the current screen depth,
> and
> > it only works for a limited number of depths (32,
> 24,
> > 8 and 1). Cairo 1.0.2 always uses
> CAIRO_FORMAT_RGB24
> > and that seems to work fine for a depth of 16 bpp.
> > Would it be ok to make the win32 backend default
> to
> > CAIRO_FORMAT_RGB24 when it can't find an exact
> match?
> 
> We did recently fix this within the 1.1 series. I
> hadn't realized that
> this was a regression that managed to sneak in
> between 1.0.2 and 1.0.4
> though.
> 
> If the 1.2.0 release weren't coming out so soon I'd
> say it would
> probably make sense to do a 1.0.6 to fix this. But
> 1.2 really will be
> soon, so it's probably not necessary.

Ok, but perhaps the 1.0.4 release should somehow be
marked as unsuitable for use on the win32 platform?
Should it really be referred to as "production-ready"
when it doesn't work if the user has a 16-bit desktop?

Also, 1.0.4 seems to be part of Tor Lillqvists GTK+
release for Windows. Perhaps it should be downgraded
to 1.0.2?

Lastly, I notice that the new code in 1.1.10 doesn't
support 4-bit displays. According to an old FAQ I
found
(http://community.borland.com/article/0,1410,15741,00.html)
4 is a possible return value for GetDeviceCaps( hdc,
BITSPIXEL ). I don't know how the 1.0.2 way of
defaulting to CAIRO_FORMAT_RGB24 would work on a 4-bit
display, but I propose providing a reasonable default
when an exact fit can't be found.

Best regards

Mikael Claesson


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com