On Thu, 03 Mar 2011 15:46:15 +0100, Jesper Saxtorph <jesper.saxto...@prevas.dk> wrote:
> I have just submitted a bugraport + a patch on trac (bug #716). > > I just wanted to notifify it here also as I do not know the > enlightenment community and how it works. > Either is fine. > To repeat my bug report: > "I use imlib2 as a image library in a project. However the use we have > sometimes tricker a situation where imlib2 uses an invalid cache. > > imlib2 uses timestamps to test if a image cache i valid. If a files > modification time is in the future it is not possible to use validation > scheme. Further if the timestamp is equal to now, we do not know if the > modification time is in the future or not. The result is that the cache > should be invalidated for file timestamps >= now. > An example of a problematic situation: timestamps are in whole seconds > times given as here as seconds: > time=32.1 : image.png is written by someone > time=32.4 : image.png is loaded by imlib2 > time=32.5 : image.png is written with new data > The situation is now that the cache has the same timestamp as the file, > but the content is not the same. > > A possible fix is a 3 line patch, which I have attached. It invalidate > the cache if the files timestamp is >= now. > The patch is made agains head, however, the image.c file (where the > patch is applied) has changed very little in it lifetime, so it works > fine with earlier versions of imlib2 (I use it against 1.4.2)." > > I attached an incorrect patch at first to the ticket, but have submittet > the correct afterwards. Sorry for that. > > My suggestion to a patch (I have made the long comment as I think it is > not obvious why it is needed): > --- imlib2/src/lib/image.c.orig 2011-03-03 14:23:49.000000000 +0100 > +++ imlib2/src/lib/image.c 2011-03-03 14:45:19.000000000 +0100 > @@ -1017,6 +1017,18 @@ > im->key = __imlib_FileKey(file); > } > im->moddate = __imlib_FileModDate(file); > + /* If the file modify time is now or in the future, we can not make > a */ > + /* cache. */ > + /* One of several possible scenarios: */ > + /* time=now: file is written by someone */ > + /* time=now: file is loaded here */ > + /* time=now: file is written again by someone */ > + /* Now we have a file a timestamp equal to our cache, but with a */ > + /* different content. */ > + if (im->moddate >= time(NULL)) > + { > + dont_cache = 1; > + } > /* ok - just check all our loaders are up to date */ > __imlib_RescanLoaders(); > /* take a guess by extension on the best loader to use */ > > Hope it make sense, otherwise feel free to ask and/or discuss it > I see there is a problem, but I don't think it is the proper solution. If you have a file with a "now"/future time stamp it would never be cached, which is wrong. How about in stead changing line 986 (svn) to check whether the time stamp has changed in stead of checking if it is newer? /Kim ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel