--===============0085409897==
Content-Type: multipart/signed;
  boundary="nextPart3321696.XYkN5MfVUV";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3321696.XYkN5MfVUV
Content-Type: text/plain;
  charset="ansi_x3.4-1968"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 04 June 2007, Cyrille Berger wrote:

> I don't think one lock on the datamanager lock the entire paint device, as
> you only need to "speak" with it when fetching a tile. So right, one lock
> on the tilemanager, serialize access to the swapfile, while one lock to t=
he
> datamanager serialize getting new tiles.

Isn't the memory for new tiles also coming from the tilemanager?

> > And, yes, a dedicated thread for memory management would be cool. It
> > would also be the place to do the compression of (undo) tiles before
> > swapping them out.
>
> yup. I hope Bart is taking notes of cool stuff to do :D

I've just committed a small cleanup -- remove the two separate locks for po=
ol=20
and swap -- because all of the tilemanager was already locked by the BKL so=
=20
the extra two locks were superfluous.

=2D-=20
Boudewijn Rempt=20
http://www.valdyas.org/fading/index.cgi

--nextPart3321696.XYkN5MfVUV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGZHuJdaCcgCmN5d8RAlRbAJ9YO0ejNDzLWrfhCUf4NdOouDe4VQCguA7J
8ciDqO6HW9N7mfRoRFmfft4=
=3Z7l
-----END PGP SIGNATURE-----

--nextPart3321696.XYkN5MfVUV--

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

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

--===============0085409897==--