[cairo] Problem with text rendering on Win32+ClearType, and possible fix

[Owen Taylor]

On Wed, 2006-10-04 at 21:15 +0000, Vladimir Vukicevic wrote:
> ----- Owen Taylor <otaylor at redhat.com> wrote:
> > I can't say I'm that perfectly happy with the current state of 
> > cairo-win32-surface.c. There's lots of confused comments, 
> > #if 0'ed out code, etc. :-(
> 
> Yep, there's a number of things in there that didn't receive enough
>  testing to turn on, but I didn't want to remove the code outright. 
>  Things like using StretchDIBits and potentially StretchBlt fall into
>  that category.  My testing is mostly with mozilla and the cairo test
>  suite, along with a few one-off test programs, so it's certainly not
>  extensive.  I've actually been at Microsoft the last few days, and I'm
>  trying to get answers for some of the outstanding GDI questions that
>  will have a direct effect on the win32 implementation.  So it's very
>  much a work in progress, as I'm trying to squeeze out as much as I can
>  out of GDI.
> 
> At this point though, it's looking like I might just get the damn thing
>  into a working state and then leave it alone, and move on to working
>  on a DirectX-backed surface, as that seems to be the way the world's
>  going.  

Certainly we're never going to get much hardware acceleration for
the advanced rendering in Cairo via GDI. It's no coincidence that
GDI+ is pretty much pure software rendering. My assumption was always
that a DirectX backend was the way to get more substantial hardware
acceleration.

>  You're right about the DDB vs. DIB issues, by the way; I'll
>  probably add some more explicit code in there to request DDBs, because
>  we're seeing significant performance tradeoffs between different
>  hardware.  On most modern hardware, "24-bit" DDBs are implemented as
>  32-bit xRGB; 24-bit DIBs are a disaster and need to be avoided at all
>  costs (the thing that "breaks" is that pixman can't handle packed
>  pixel, as far as I could tell, or something similar; 

Indeed.

> the fact that
>  CAIRO_FORMAT_RGB24 is defined to be 32-bits isn't really relevant, as
>  nothing can access the data directly other than the surface itself).

Well, I guess you could put it that way. But right now, the way that
the Win32 format refers to pixman image types is via there
CAIRO_FORMAT_* names, so it at least somewhat relevant.

(If cairo_win32_surface_create() was made to recognize existing DIB's,
then it would need access to other pixman image types. Right now, we
always go the other way - pick a CAIRO_FORMAT_* and create a DIB for
it, so we we can escape that issue.)

> In any case, the win32 surface stuff is actively being worked on, so
> it's bound to be a little messy in between releases especially with so
> few users.

I'm not sure that the number of end users is small, but the number
of users in a position to contribute is definitely small, considering
the barriers of git on Win32 and the lack of a standard build setup.

					- Owen