Op 06-12-2018 om 12:03 schreef Maarten Lankhorst: > Op 05-12-2018 om 11:24 schreef Basile Clement: >> Hi, >> >> On 12/5/18 9:08 AM, Pekka Paalanen wrote: >>> On Tue, 4 Dec 2018 17:36:18 +0100 >>> Maarten Lankhorst <maarten.lankho...@linux.intel.com> wrote: >>>> Series looks sane, 1/4 is cleaner than my version. I would change Bpp >>>> to cpp, or multiply by 8, since Bpp usually means bits per pixel. >>> And cpp means channels-per-pixel? >>> >>> B usually means bytes, b often means bits. But not always, so you can >>> never assume. >>> >>> I'd just write out bits_per_pixel or bytes_per_pixel, just like >>> pitch_bytes or stride_pixels or stride_uint32s or whatever makes it >>> totally obvious. >> This was indeed Bpp as in Bytes-per-pixel; I reused the variable name from >> pixman-general.c. Happy to change it to the more explicit bytes_per_pixel. >> >> On 12/4/18 5:36 PM, Maarten Lankhorst wrote: >>> Do you happen to have a patch to fix pixman-bits-image.c falling back to >>> 8-bit paths as well? >> Are you referring to the fact that `get_scanline_float` gets data through >> `get_scanline_32` first? If so, I have not -- I understand this is only an >> issue with floating point formats, which were added after I wrote the >> patches. > This is also an issue with any format with >8 bpp, see > PIXMAN_FORMAT_IS_WIDE(). This also affects the 8-bit sRGB format, and > PIXMAN_x2r10g10b10 and its variations. > > ~Maarten > > _______________________________________________ > Pixman mailing list > Pixman@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pixman
Looks easier to add than expected. I've mostly completed my commit that does the same for pixman-bits-image, but might conflict with this series.. _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman