Re: [Pipmak-Devel] This code show the image-cache-bug...
Status: Alpha
Brought to you by:
cwalther
From: Christian W. <cwa...@gm...> - 2008-01-02 17:26:28
|
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 |