Andrea Viarengo wrote:
> -- draw a BLACK square at the left of red square
>=20
> img2=3Dpipmak.loadimage("black.png")
> draw{distance=3D4,lateral=3D2,height=3D0,image=3Dimg2}
>=20
> -- draw a BLACK square at the right of red square
>=20
> img3=3Dpipmak.loadimage("black.png")
> draw{distance=3D4,lateral=3D-2,height=3D0,image=3Dimg3}
>=20
> -- draw a RED square above the first red square
>=20
> img4=3Dpipmak.loadimage("black.png")=20
> -- next statement show the bug:
> -- all the square become red!!!! Why?????
> img4:color(1,0.5,0.5,1):fill()
> draw{distance=3D4,lateral=3D0,height=3D2,image=3Dimg4}
I've just had a look at this, and I've come to the conclusion that it=20
works as designed - though admittedly the design is flawed.
What trips you up is this (from section 3.12 "Image Manipulation" of the =
reference):
"pipmak.loadimage(filename) ... Calling this function multiple times=20
with the same path returns the same object, and the image is only=20
reloaded from disk if it isn=92t already in memory."
So what happens is that img2, img3, and img4 all refer to the same=20
object, and when you modify that object in the second-to-last line, the=20
change reflects in all three patches that use it.
(img1 is not involved because you modify it before loading img2, so at=20
that point loadimage knows that it really needs to reload the file and=20
give you a new image object.)
I'm not sure what the best solution to this is. I don't think giving up=20
the returns-the-same-object behavior of pipmak.loadimage is a good idea, =
as I rely on it in many places. I'll try to think of something better,=20
but in the meantime I just wanted to let you know this much (I've kept=20
you waiting long enough...).
Thinking out loud: The fundamental issue is that the caching behavior of =
pipmak.loadimage, which was good for immutable objects, clashes with the =
fact that images have now become mutable. Perhaps some kind of=20
copy-on-write scheme could reunite the two.
-Christian
|
