[cairo] MIPMAPPING cairo.

Jeff Muizelaar jeff at infidigm.net
Mon Nov 3 11:26:43 PST 2008


On Mon, Nov 03, 2008 at 12:02:15PM -0500, Frédéric Plourde wrote:
> Jeff Muizelaar had written :
> >A couple other high level comments:
> >1. It doesn't look like the mipmap generation doesn't deal with source
> >clipping...
> >  
> could you provide me with a test case for that ?  I had tested the 
> clipping case in the past and everything seemed ok., thanx.

pixman/test/clip-test.c should test it. I've also attached a simpl test
case that will exercise the code path.

> >2. Does the mipmap generation code deal with images that have a bytes per
> >pixel that isn't 4?
> >  
> mhh... yeah, it should be ok, since pixman_image bits are uint32_t anyways.

uint32_t doesn't represent the number of bytes per pixel just the
alignment constraints.

> And if you take a closer look at all 
> fbFetchMipmapResize_Linear_Mipmap_.... functions, it's been implemented 
> in the very same way than the three fbFetchMipmapResize_Bilinear_...  
> functions where
> I retrieve the fetch function through "fetch = 
> ACCESS(pixman_fetchPixelProcForPicture32)(pict);" and below, a call to 
> "do_fetch" should fetch pixels correctly whatever the pixman pixel 
> format we use.

In my reading of the code pixman_build_mipmap() does:

MEMCPY_WRAPPED(pict, pict->mipmap.levels[0].bits, pict->bits, pict->mipmap.base_width * pict->mipmap.base_height * sizeof (uint32_t));

which seems to read directly from pict->bits ignoring the number of
bytes per pixel.

-Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source-clip-test.c
Type: text/x-csrc
Size: 1469 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20081103/37ca92a3/attachment-0001.c 


More information about the cairo mailing list