On Thu, 10 Mar 2011 10:31:32 +0100, Carsten Haitzler  
<ras...@rasterman.com> wrote:

> On Sun, 06 Mar 2011 07:49:59 +0100 "Kim Woelders" <k...@woelders.dk> said:
>
>> 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?
>
> while in general you are also right.. he's also trying to fix the  
> problem of
> "write file at 34.1 secs, then write AGAIN at 34.5 secs" - they both  
> have the
> SAME timestamp but the 2nd is newer. imlib2 will not load the newer file  
> as the
> timestamps match due to timestamp resolution (34 vs 34 secs). but while  
> solving
> this problem it  breaks caching for timestamp == now. you'd need much  
> higher
> resolution timestamps (and even then you still just have a smaller race
> condition) or .. you'd have to have another way to differentiate the  
> files.
> file size + timestamp + inode + .... even then you just lower the  
> probability
> not eliminate it.
>
Yeah, I know.

The important thing here, IMO, is that images which never change, should  
always be cached (unless explicitly not caching), whichever  
past/now/future time stamp they may have.

How about this:

diff --git src/lib/image.c src/lib/image.c
index d404961..e8610b2 100644
--- src/lib/image.c
+++ src/lib/image.c
@@ -982,8 +982,10 @@ __imlib_LoadImage(const char *file,  
ImlibProgressFunction progres
               time_t              current_modified_time;

               current_modified_time = __imlib_FileModDate(file);
-             /* if the file on disk is newer than the cached one */
-             if (current_modified_time > im->moddate)
+             /* if the disk file time stamp is different from the */
+             /* cached one or appears to have just been set */
+             if ((current_modified_time != im->moddate) ||
+                 (current_modified_time == time(NULL)))
                 {
                    /* invalidate image */
                    SET_FLAG(im->flags, F_INVALID);

This of course requires using imlib_image_set_changes_on_disk() in the  
application.

/Kim

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to