Re: libpng and multithreading

--===============4237443950567870527==
Content-Type: multipart/alternative; boundary="000000000000af241305f20094bf"

--000000000000af241305f20094bf
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 10, 2023 at 11:46 PM Lee Shallis <[email protected]> wrote:

> [F] for any row, column or diagonal to be made multi-threaded despite
> depending on
> local pixels, you can make an additional boolean array for declaring a
> pixel done, this is just a fall back in case the threads dsync,
>

I don't think that is necessary because the filters do not depend on
the *result
*of the prior row or pixel filters; rather they use the original
pixel-component values.  This does force some serialisation of the *read *code
but not the write code and it is the write side which benefits more from
parallelization.  The benefit isn't speed; creating a PNG fast is trivial
since the "none" filter can be combined with Zlib level 0 though the last
time I tested this kind of thing Zlib levels 1-3 were often faster because
of the actual write-to-disk speed increase.

The read side is more complex because of the need to do Zlib first; both
the Huffman decoding and the window lookup.  Having done that the chance of
doing parallel filter operations depends on finding the filter bytes in a
partially decompressed stream.  I can see ways of doing the Huffman
decoding in parallel but I don't know how to do the window lookup, maybe
someone has done it but parallel *decoding *of Zlib/deflate seems like it
would have only restricted use; it requires the compressed data to be
available first!

--000000000000af241305f20094bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jan 10, 2023 at 11:46 PM Lee Shal=
lis &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:=
<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">[F] for any row, column or diagonal to be made multi-threaded d=
espite depending on<br>
local pixels, you can make an additional boolean array for declaring a<br>
pixel done, this is just a fall back in case the threads dsync,<br></blockq=
uote><div><br></div><div>I don&#39;t think that is necessary because the fi=
lters do not depend on the <i>result </i>of the prior row or pixel filters;=
 rather they use the original pixel-component values.=C2=A0 This does force=
 some serialisation of the <i>read </i>code but not the write code and it i=
s the write side which benefits more from parallelization.=C2=A0 The benefi=
t isn&#39;t speed; creating a PNG fast is trivial since the &quot;none&quot=
; filter can be combined with Zlib level 0 though the last time I tested th=
is kind of thing Zlib levels 1-3 were often faster because of the actual wr=
ite-to-disk speed increase.</div><div><br></div><div>The read side is more =
complex because of the need to do Zlib first; both the Huffman decoding and=
 the window lookup.=C2=A0 Having done that the chance of doing parallel fil=
ter operations depends on finding the filter bytes in a partially decompres=
sed stream.=C2=A0 I can see ways of doing the Huffman decoding in parallel =
but I don&#39;t know how to do the window lookup, maybe someone has done it=
 but parallel <i>decoding </i>of Zlib/deflate seems like it would have only=
 restricted use; it requires the compressed data to be available first!</di=
v></div></div>

--000000000000af241305f20094bf--


--===============4237443950567870527==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============4237443950567870527==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

--===============4237443950567870527==--