[cairo] Problem with text rendering on Win32+ClearType, and
otaylor at redhat.com
Wed Oct 4 14:55:30 PDT 2006
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
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
> 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;
> 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.
More information about the cairo