<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Hi Graeme,</p>
<p> </p>
<p>I will test the app you made on Mac as well. On Windows I think the performance will be similar now.</p>
<p> </p>
<p>As for the delay in startup, don't worry that is the file cache being created. It's not more than a stream of raw pixel data for each frame and a simple list of stream references for each frame. In my "new" version which is also in CCR this loading is actually pretty fast now. It takes a sec or 2 to setup. I'm sure this could be improved, but that is only a minor problem for now.</p>
<p> </p>
<p>Regards, Darius</p>
<p> </p>
<p> </p>
<p> </p>
<p>On 10 feb '12, Graeme Geldenhuys wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<pre>2012/2/9 Darius Blaszyk :</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">I've put up the test app on the CCR. All three methods draw at roughly 10fps on windows and 6fps on mac.</blockquote>
<pre>Using your project as-is, I get 9fps under Linux. Also I have a 10-20
seconds delay just for the program to start up - I didn't investigate
this.
I then went and modified your TImage code to look as shown below...
Basically this is so I can do a direct comparison to my fpGUI test
project. It now loads 1.5Mbyte BMP versions of your images. This gives
me a 7fps animation. Yuck! Oh, and I had to enable double buffering,
otherwise I would have gone into shock. ;-)
----------------------------
procedure TForm1.mnuTImageClick(Sender: TObject);
var
s: TDateTime;
i: integer;
j: integer;
f: boolean;
begin
PageControl1.ActivePage := ImageTabSheet;
s := Now;
for i := 1 to 23 do
begin
Image1.Picture.LoadFromFile(Format('./images_50/%.4d.bmp', [i]));
Application.ProcessMessages;
end;
AddTestToListBox('TImage', 23 / ((Now - s) * 24 * 3600));
end;
----------------------------
So this got me thinking. We already know that fcl-image really really
sucks at loading images from disk. fpGUI proves with it's own JPG and
BMP loading code, that it could be done in a fraction of the time it
takes fcl-image.
So to prove this point further, I quickly implement PNG support in
fpGUI, by using the fcl-image loading code, and populating a TfpgImage
instead. Now my fpGUI based animation test can use BMP, JPG and PNG
images.
The result....using 50% HD images.
BMP (native) in fpGUI.... 100fps
JPG (native) in fpGUI... 37fps
PNG (via fcl-image) in fpGUI.... 8fps
So this clearly shows one huge bottleneck... Loading via fcl-image is
very bad! The FPC team really needs to investigate this further.
Unfortunately I haven't implemented native PNG loading in fpGUI yet,
but you are welcome to port the BMP or JPG code to your LCL
application. This shouldn't be hard, because the code doesn't have
much to do with GUI toolkits. Though that means your images need to be
converted too - which I gather you would rather not want to do.
My fpGUI animation test project and the image samples can be
downloaded from the following URL. If your ISP bans DynamicDNS sites,
email me in private and I'll send it to you directly.
<a href="http://opensoft.homeip.net:8080/~graemeg/animation_test.tar.gz">http://opensoft.homeip.net:8080/~graemeg/animation_test.tar.gz</a> (2Mb)
</pre>
</blockquote>
<p> </p>
<p> </p>
<div> </div>
</body></html>