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

[Maarten Lankhorst]

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.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
>
> _______________________________________________
> Pixman mailing list
> Pixman at 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..