[Pixman] [PATCH 7/7] utils.c: Increase acceptable deviation to 0.0064 in pixel_checker_t

[Søren Sandmann]

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

>> The specific dither algorithm I used was a variant of ordered dither
>> using the dither matrix from GdkRGB
>> 
>>    http://git.gnome.org/browse/gtk+/tree/gdk/gdkrgb.c?id=2.24.15#n968
>> 
>> which is a 128 x 128 table containing 256 copies of the values from 0 to
>> 63 arranged in a blue-noise pattern.
>
> If we care about the performance, using 128 x 128 table might be not the
> best choice (due to the possible L1 cache misses when accessing this
> table). Does using smaller tables result in significantly worse looking
> images?

My guess is that a 64x64 table would be fine for 565, but I don't have a
convenient way to test. For lower bitdepths such as a1, smaller tables
would perhaps be more visible.

> OK, but I'm still not quite sure about how this more accurate
> r5g6b5 <-> x8r8g8b8 conversion & dithering fits the 16bpp rendering
> pipeline. If we have many intermediate color depth conversions
> happening during processing, the final image quality is not going
> to be very good anyway.

By "16bpp rendering pipeline" do you mean Jeff's proposal here: 

 http://lists.freedesktop.org/archives/pixman/2012-July/002174.html  ? 

Part of the idea with tolerance based testing is to get away from the
concept of n-bit pipelines and instead just have compositing routines
that use enough internal bits that they can satisfy the tolerance based
test. It may still be that general_composite_rect() will convert to 32
bits or floating point internally, but it would no longer be possible
for the test suite (or users) to rely on bit exact arithmetic.

> It is easier to just switch to doing every intermediate rendering
> using a8r8g8b8/x8r8g8b8 format and perform dithered conversion of the
> final picture to r5g6b5 as the final step (if the target image or
> framebuffer is using 16bpp color format).

This (dithering the final picture to r5g6b5) is what I think should be
done if we add support for dithering. That is, dithering should only be
turned on if the user explicitly requests it by calling something like

       pixman_image_set_dithering (image, ...)

on the destination image.

> But if all the intermediate rendering is done with 16bpp (for the memory
> bandwidth saving reasons) then it may make sense to just apply a few
> tweaks or hacks here and there, like the patch from Jeff Muizelaar:
>
>     http://lists.freedesktop.org/archives/pixman/2012-July/002174.html
>
> It would be clearly cutting some corners. But if the performance is
> the primary goal no matter the quality reduction (where it does not
> bother the users), then this might be a good thing to do. And also
> as gradients are by far the worst offenders contributing to banding
> artefacts, directly generating 16bpp dithered gradients and possibly
> caching them looks like a useful tweak.

Yes, directly dithering gradients could be a useful tweak, though I
don't see why the dithering (adding noise) has to happen at the same
time as the downconversion. Ie., we could conceivably add something like

     pixman_image_set_dithering (image, pixman_format_code_t)

that would only apply to *gradients* and would cause the intermediate 32
bit pixels to get noise added to them such that the after conversion to
the given format, they would be properly dithered. Users would then
usually pass the destination format for the operation that they were
going to do.

However, unless using 16 bpp for the internal buffers is really a
performance win, there doesn't seem to be any benefits to doing it this
way over just dithering the final image. And I definitely want to see
convincing numbers before believing that 16 bpp for internal buffers is
a performance benefit.

>> > As for x86, I believe that r5g6b5 format is not in use anymore.
>> 
>> If phones or tablets with Atom chips start appearing, I suppose that
>> might change.
>
> If I understand it correctly, Android is gradually changing to
> prefer 32bpp color depth:
>
>     http://www.curious-creature.org/2010/12/04/gingerbread-and-32-bits-windows/
>     http://www.curious-creature.org/2010/12/08/bitmap-quality-banding-and-dithering/
>
> Atom chips do not seem to be suffering from the very limited memory
> bandwidth of the early ARM chips. The modern ARM chips also have
> significantly improved and Exynos5 in ARM Chromebook is particularly
> good (12.8GB/s of theoretical memory bandwidth, and ~6GB/s of it really
> available to the CPU). I expect that r5g6b5 does not have much time
> left even in mobile devices and will eventually disappear for real.

You are probably right about this, though personally I think 565 with
good dithering can look pretty much indistinguishable from 8888.


Søren