Testing output from each backend (was: [cairo] State of Win32 backend?)

[Tor Lillqvist]

Owen Taylor writes:
 > The test are expected to fail in this case ... the reference images
 > are four-channel.

Oh, I see.

 > But if the images don't look right at all when using RGB24, then
 > that might indicate a problem with cairo_surface_write_png().

Hmm. I'll have a look.

 > The only correct way to do this operation under Unix is to use
 > dup2(), so unless that works under Windows (seems unlikely)

Yes, dup2() does work on Windows. (It's handled by the C library, not
the OS, but it does works like on Unix.)

 > > +    *closure = surface = _cairo_win32_surface_create_dib (CAIRO_FORMAT_ARGB32, width, height);

 > I don't like this much. The stuff in test/ should only be using public
 > API ... the above isn't even going to work if we start properly
 > controlling exports to the DLL, right?

Well, code duplication doesn't sound like a good idea either. Should
this functionality then be promoted to public?

 > Now the basic conceptual problem is that there aren't hardware
 > accelerated ARGB32 destination surfaces in the win32 backend ....

Hmm. I don't understand... but then I can't claim understanding much
of cairo anyway ;-)

Do you mean that cairo-test *should* test CAIRO_FORMAT_RGB24 formats?
If I do that the tests all fail badly currently. The *-win32-out.png
files end up mostly black. Could this be because RGB24 surfaces are
still created as 32-bit DIBs in _create_dc_and_bitmap(), and the code
then expect them to actually contain true alpha bytes, even though
these are never initialized? Or something like that?

 > > -           *rowstride_out = (width + 1) & -2;
 > > +           *rowstride_out = ((width - 1)/4 + 1) * 4;

 > > -           *rowstride_out = ((width + 15) & -16) / 8;
 > > +           *rowstride_out = ((width - 1)/32 + 1) * 4;

 > These gives bad results for width == 0... while that may not 
 > matter much, I'd rather see correct expressions. It's easy
 > to adapt the original to the dword alignment case.

Hmm, but my eyes glaze over when I see bitwise operations with
negative integers (other than -1)... Using just the four arithmetic
ops makes it somewhat easier to understand, IMHO. 

--tml