[cairo] Cairo on older Windows

Owen Taylor otaylor at redhat.com
Mon Nov 6 14:47:49 PST 2006


On Mon, 2006-11-06 at 14:00 -0800, Carl Worth wrote:
> On Mon, 6 Nov 2006 13:34:39 -0800 (PST), Jeff Smith wrote:
> > I keep hearing about Firefox 3.0 making a major shift to Cairo, but
> > that this will result in dropping support for Windows 95/98/Me.  Is
> > this really a Cairo issue?
> 
> I've been told that cairo's win32 backend relies on functions that do
> not exist in Windows 95 or Windows 98, (I have no idea about Windows
> Me). One such function is SetWorldTransform, but there could be more.

Certainly the main sticky point at the point I was working on it was
transformed text. Win9x can only do rotated text, not text with 
an arbitrary transform. And rotated text is done in a completely 
different way than on newer Windows. If you are willing for all
transformed text to be broken, it should be pretty trivial to get
cairo working.

AlphaBlend was another thing present only on recent versions of Windows,
but it's easy to work around, and there is already some of the code
to do it in the tree.

> >                            If so, is there an explaination
> > somewhere as to why Cairo cannot (or will not) be supported on these
> > older iterations of Windows?
> 
> One approach to making cairo work for ancient versions of Windows
> would be to basically use cairo's image backend for everything and
> then just blit the results back and forth as necessary. A similar
> approach is used for the xlib backend for old X servers without the
> Render extension for example.

Because the hard bit is text rendering, this doesn't quite work.
You still need Windows to draw the glyphs; the thing you want
to do probably is:

 - Use windows rendering for the normal cases of scaled and
   rotated text.
 - Fall back all the way to rendering via glyphs if someone
   actually shears text.

This isn't *hard* but it's not 1:1 replacement of existing code;
rather it's a question of integrating two quite different ways
of going about things into the same code base.

Also, for Windows XP I was unable to figure out how to get the
right glyph metrics simply by reading the docs; I had to instead
determine things experimentally; the same sort of experimentation
would be necessary for Win9x.

> It won't necessarily be fast, but it will actually function at
> least. Making it be as fast as possible would require working to
> minimize the blits in both directions, and to really do this well
> might require the application to tell cairo when a particular
> operation is "done". (But if the application is going to be modified
> for performance here, it would probably be easier to leave the cairo
> API alone and just make the application use cairo's image surfaces
> directly.)

Actually, the windows code in Cairo handles software fallbacks a lot
better than the Xlib code; for one thing it frequently will use a DIB,
so cairo  native rendering and Windows native rendering can go to the
same buffer. There is still room for improvement, but I don't think 
it would particularly be more of an issue on Win9x then 
on 2000/XP/Vista.

> If someone were to attempt a fix like that, it should probably be
> pretty simple--basically just a matter of returning
> CAIRO_STATUS_UNSUPPORTED from the right places in the win32 backend,
> and then letting existing fallback paths in cairo take care of all the
> rendering to image surfaces and blitting.

I think really the simple answer to why Win9x is not currently supported
and is not likely to be supported is that there is no interest in doing
the work.

While Win9x may still be present on millions of systems, almost all
these systems are pretty much unmaintained. Certainly few developers,
open source or otherwise, are running Win9x.

So, the first criterion is to find someone who meets two or more of 
following criteria:

 - Is passionate about Win9x (do such people exist?)
 - Has a financial motive to get cairo running on Win9x
 - Loves a challenge

					- Owen




More information about the cairo mailing list