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

[Owen Taylor]

On Tue, 2005-05-10 at 10:33 +0300, Tor Lillqvist wrote:

>  > 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.)

As long as it can be used to redirect stderr by 
close(2), dup2(otherfd,2), it can be used.

>  > > +    *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?

The public version of this functionality already exists:

 cairo_image_surface_new (CAIRO_FORMAT_ARGB32, width, height);

But doing the "win32" test cases like that would be silly :-)

>  > 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 ;-)

There is no rocket socket here. The Win32 backend has two modes:

 - Draw directly to a destination. Some operations are
   done accelerated (drawing text, alpha and non-alpha blitting),
   some operations are done with get-image / draw / put-imgae
   software fallbacks.
  
   This mode is never used for destinations with alpha, since 
   the Windows GDI has no concept of drawing to a window with
   alpha.

   This mode would be interesting to test.

 - Draw to a 32-bit DIB by wrapping it in a cairo_image_surface_t.
   All operations are simply passed through to the image backend.

   This is what is used for destinations with alpha.

   Once the basic wrapping has been tested, there is nothing else
   interesting to test here.

> 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?

If we were testing CAIRO_FORMAT_RGB24 images, we'd need an entirely
different set of reference images, and some of the tests might need
modification as well.

I'm really suggesting that perhaps we should skip adding Win32 backend
tests if they aren't going to do any good.

>  > > -           *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. 

But it isn't equivalent... because of C's stupid arithmetic rules,
an equivalent expression not using bitwise ops requires conditionals.

The & -2 is certainly an "idiom" ... something that you just remember. 

I don't have any objections to writing:

 (width + 15) & ~15

instead, which may be clearer, depending on your tastes.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050510/79ecd4ea/attachment.pgp