pstone has asked for the wisdom of the Perl Monks concerning the following question:

Greetings!

I've found this question before but I'm no understanding the process to completing this successfully.

My problem is this... take a look at http://www.disksleeves.com/, choose a letter of sleeves to look at and then pick a sleeve... if you keep going forwards or backwards to the next or previous sleeve, you'll see what's happening...

The image of an old sleeve is shown before the new one pops up HOWEVER the script has the command to show the .GIF being written AFTER the write command...

naturally, this is apparently a common problem yet I can't solve it. Wait doesn't work. FLOCK doesn't do anything - etc...

The code is basically:

--- 

$newimage->copyMerge($watermark, 30, 165, 0, 0, 350, 80, 15);

$maxtotal = 30;
$totalnum = 0;

open (xx,"<$cascade");
@totalnum = <xx>;
close (xx);

$totalnum = @totalnum[0];
$totalnum ++;

if ($totalnum > $maxtotal) {
    $totalnum = 0; 
}

open (xx, ">$cascade") or die("Cannot open file for writing");
print xx "$totalnum\n";
close (xx);

$temppic = "/home/u4/dat3/html/dsa/temppics/$totalnum.gif";

open(PICTURE,">$temppic") or die("Cannot open file for writing");
flock(PICTURE, LOCK_EX);
binmode PICTURE;
print PICTURE $newimage->gif;
close PICTURE;

print "<img src=\"/dsa/temppics/$totalnum.gif\" width=\"400\">
\n\n";

So natually, between "close PICTURE;" and the next "print "<img src=..."" line, there needs to be a way to delay until the CLOSE actually CLOSES!

Unfortunately, FLOCK didn't work - I did it and still I got the quick flash of the previously stored sleeve...

NOW I've also tried to bypass the writing of a temp file altogether and spit the gif output directly to the screen but I can't get that to work as every attempt simply spits the ASCII of the gif out, even with BINMODE yet I can do it on it's own in a test .pl file - The difference there is that the test file is just spitting out the image - nothing else where as this already has html spit out and changing the content: to gif doesn't work like it does in my stand along test file.

OK - hopefully this made sense!

Thanks Peter I would rather just do that and have no
  • Comment on How to wait until GD Image it written, then continue

Replies are listed 'Best First'.
Re: How to wait until GD Image it written, then continue
by jethro (Monsignor) on Jan 15, 2009 at 16:34 UTC
    I didn't see old images when I visited your site and tried it (with SeaMonkey or Firefox). Could this be just a caching issue with your webbrowser?
[reply]
      /grumble

      WHY Firefox WHY? You moved the headstones but you left the bodies! WHY!?

      Well.. heh... that was it - I was going crazy - local cache issue...

      Is there some spooky content command or something to tell a user's browser to not cache files or something like that so this doesn't crop up for other users?

      The issue is that the # of files is set to 30 then it wraps and sure enough, once a user looks at 30 sleeves, this starts to happen. :P
[reply]
        Is there some spooky content command or something to tell a user's browser to not cache files or something like that so this doesn't crop up for other users?

        these HTTP header values may be relevant 

        'Pragma'    =>    'no-cache' 
'Cache-Control'    =>    'no-cache'
'Expires'    =>    0

        [download]
        another method is to make sure the URL is different each time (e.g. by appending a GET parameter showing the current datetime).

        hth!

        a.

        update: don't forget, the user's browser isn't the only place that caching can occur. it can happen at your end, at the user's end, or anywhere in between (e.g. reverse caching proxy at the ISP)

[reply]
[d/l]

        The following works for me: 

        my $q = CGI->new;

print $q->header(
    -expires => '0',
    -pragma => 'no-cache',
    -cache_control => 'no-store, no-cache, max-age=0, must-revalidate'
+,
);

        [download]
[reply]
[d/l]
        Take a look in RFC 2616 for the 'cache-control' HTTP header.
[reply]

Back to Seekers of Perl Wisdom