[Pixman] [PATCH 1/4] Implement floating point gradient computation

Maarten Lankhorst maarten.lankhorst at linux.intel.com
Thu Dec 6 11:03:31 UTC 2018


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.lankhorst at 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



More information about the Pixman mailing list