Delphi TGIFImage animation issue with some GIF viewers

后端 未结 2 2137
闹比i
闹比i 2021-02-20 08:02

I have discovered that animated GIFs created using Delphi 2009\'s TGIFImage sometimes doesn\'t play correctly in some GIF viewers. The problem is that the

相关标签:
2条回答
  • 2021-02-20 08:24

    Edit: This turned out not to be the answer but I'm keeping it as the rule about the loop extension still applies.


    The NETSCAPE loop extension must be the first extension:

    var
      Frame: TGIFFrame;
    ...
    for i := 0 to 499 do
    begin
      MakeFrame(i);
      Frame := g.Add(bm);
      if (i = 0) then
        TGIFAppExtNSLoop.Create(Frame).Loops := 0;
      TGIFGraphicControlExtension.Create(Frame).Delay := 3;
      Writeln('Creating frame ', i+1, ' of 500.');
    end;
    

    See: The TGIFImage FAQ.

    Apart from that I see nothing wrong with your GIF, but you could reduce the size a bit with a global color table.

    0 讨论(0)
  • 2021-02-20 08:29

    It's a bug in TGIFImage's LZW encoder.

    In some very rare circumstances the LZW encoder will output an extra zero byte at the end of the LZW steam. Since the LZW end block marker is also a zero byte, a strict GIF reader might choke on this or interpret it as the end of the GIF (although the end of file marker is $3B).

    The reason some GIF readers can handle this is probably that GIFs with this problem was common many years ago. Apparently TGIFImage wasn't the only library to make that particular mistake.

    To fix the problem make the following modification to gifimg.pas (change marked with *):

    procedure TGIFWriter.FlushBuffer;
    begin
      if (FNeedsFlush) then
      begin
        FBuffer[0] := Byte(FBufferCount-1); // Block size excluding the count
        Stream.WriteBuffer(FBuffer, FBufferCount);
        FBufferCount := 1; // Reserve first byte of buffer for length
        FNeedsFlush := False; // *** Add this ***
      end;
    end;
    
    0 讨论(0)
提交回复
热议问题