[cairo] MIPMAPPING cairo.
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
> 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
> 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.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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1469 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20081103/37ca92a3/attachment-0001.c
More information about the cairo