CATWW

[Handoko]

Thank you MathMan for the suggestion.

Yes, you're right. I already figured it out and done it before reading your post. It really improves the performance.

Not only caching it the images, it now also generates multi resolution images to improve the performance when user resizing the form. On my benchmark, the more it scales, the longer the time it needed. So I made it auto generates several resolutions when loading images or user switches skin.

@TRon

Yes, version 0.1 was quickly built. Now I'm adding multi-res image generation, image caching, using buffer instead of direct drawing. Hope the version 0.2 will have good performance.

[Handoko]

CATWW Version 0.2

The performance has been improved. And now user can choose which city to be showed on the clock by clicking on the clock. Because of the size of source code (+images) is now too large to be added on this post, I put the downloadable source code on the first post https://forum.lazarus.freepascal.org/index.php/topic,50989.0.html

To keep it simple, the whole source code is only separated in 3 parts:

• The main form (Mainform.pas), which allow user to change the configuration
• The Clocks (Clocks.pas)
• The DataSync.pas, all the non-graphics calculations should be put in here

How to add the time shift calculation into the code?

The time zone lookup and time calculation code should be put in the DataSync.pas.

I quickly generated the time zone data and saved it in Cities.txt. I use TStringList's LoadFromFile and name-value pair features. It is a quick solution. But if you think it should use a database, just do it and change the related code.

Here is the interface part of DataSync.pas:

Code: Pascal  [Select][+][-]

1. unit DataSync;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, StdCtrls, Grids, DateUtils;
9.  
10. const
11.   MaxRows    = 2;
12.   MaxColumns = 3;
13.   MaxClocks  = MaxRows*MaxColumns;
14.  
15. var
16.   CityList: TStringList = nil;
17.   Cities:   array[1..MaxClocks] of string = // Empty string means
18.               ('', '', '', '', '', '');     // to use system time
19.  
20. procedure LoadCities;                // Should be called when program start
21. procedure FreeAllData;               // Should be called when program exit
22. function  GetSystemTimeName: string; // How to name the system time
23. function  GetCityName(Index: integer): string;     // Index start from 1
24. function  GetCityTimeZone(Index: Integer): string; // Index start from 1
25. procedure GetCityTime(Index: Integer; ThisSystem: TTime; var Hour, Minute: Word);
26. function  SelectCity: string;        // Show a popup for selecting a city
27.  
28. implementation
29.  
30. type
31.  
32.   { TCityPopup }
33.  
34.   TCityPopup = class(TForm)

CityList is used to store the data loaded from Cities.txt. And Cities is the data that stores the user selected city for each of the clock. The code for loading the data should be put in LoadCities and FreeAllData is for freeing all the in-memory objects.

GetSystemTimeName is the name for the clock that using the computer time. Change the return string to whatever you think better.

I do not have solution for the time zone calculation, I quickly created a fake time calculation, which is not correct. It is in GetCityTime. GetCityName is used for converting the loaded data for the city name and GetCityTimeZone are the data for saved time zone. The code of GetCityTime, GetCityName and GetCityTimeZone need to be changed.

SelectCity will be called if user want to change the city for the clock (which can be done by clicking the clock). It will runtimely create a popup based on TCityPopup class. I tested the TCityPopup on a separated code, the performance was still okay even the item count has reached 300.000. It uses TStringGrid for the drawing but data is maintained separately.

Performance improvement

The code now uses cache system and multi-resolution images, which generated at runtime. It run pretty good on my test, although I wish resizing the clocks can be faster.

Please test it.
Do it run correctly on different environment?
And do you think the performance is acceptable?

Any suggestions and criticisms are welcome.

The source code can be downloaded here:
https://forum.lazarus.freepascal.org/index.php/topic,50989.0.html

[Lulu]

tested on Win10 64b and work very well 

[Handoko]

Thank you.

Do you have any suggestions?

[Lulu]

May be use opengl ? It will be faster and also improves the memory footprint of your application:
load the 4 images 1200x1200 as texture in the gpu memory and use matrix to resize/rotate each part of the clocks.
I think this could be done 'easily' with TBGLVirtualScreen, but I never realy use it.
Or use TOpenGLControl directly.
Regards

[JLWest]

Works pretty well. Windows 10.

I like it.

[TRon]

Thank you Handoko.

That is an impressive performance boost 

The tiny pi3b+ is now even able to show the maximum amount of clocks full-screen. In case it is then there is a small (almost unnoticeable) hick-up when two or more clock-hands needs to shift graphically but that is to be expected. Before, when the improvements were not in place, it was virtually impossible to get the window bigger then a quarter screen (and for comparison that quarter size window caused a 5 sec delay for the hands to shift). Other then that I can report that it takes a small amount of time to redraw the clocks on a resize of the window but, that is also expected and negligible.

No other flickering/stuttering etc. anymore.

[Handoko]

Glad to know it is able to show full screen on Raspberry Pi 3b+.

So do you think the performance is okay and we don't need to use OpenGL or other graphics engine?

The version 0.1 is only a prototype without any performance optimization. I'm sure you ever heard "Premature optimization is the root of all evil". That's why it was very slow.

On version 0.2, I can see some short delay time when resizing. That is understandable because resizing will 'force' all caches to renew. I have some ideas that might make it better. I will try it on next version.

I'm already started working on version 0.3. The things are going to be added are mostly cosmetic improvements. Also fixing a memory leak issue, I was so careless that forget to free the multires images.

You don't need to calculate the 60 transformations if you want to cache them. For example you can calculate a quarter, say the first 15, then flip horizontally and vertically as needed, that's much faster.

I choose to calculate half of the images. Because some of the hands I planned are not symmetric.

[TRon]

So do you think the performance is okay and we don't need to use OpenGL or other graphics engine?

Nah, I think it is more than ok-ish.

You can't expect miracles on such hardware, and besides that there comes a point where you have to draw a line (phun intended)  .

I'm sure you ever heard "Premature optimization is the root of all evil". That's why it was very slow.

I understand. It was by no means meant as criticism rather an observation that could serve as some sort of indication. I also wouldn't expect the new version to run on ... let's say ... a vic-20 

On version 0.2, I can see some short delay time when resizing. That is understandable because resizing will 'force' all caches to renew. I have some ideas that might make it better. I will try it on next version.

In case it kind of bothers you, then please feel free. Personally I find it more than acceptable.

I'm already started working on version 0.3.

Cool !

fwiw any improvement with regards to speed would be noticed on this little machine. And fixes are always welcome. Sorry as I haven't been able to provide feedback on such matters.

[bytebites]

See what happens if you select same timezone than your local time.

[TRon]

See what happens if you select same timezone than your local time.

Could you elaborate on what I should be seeing (that you seem to suggest as wrong) ?

[winni]

Hi!

Berlin Shows: 21:02
Germany is now: 20:02

Winni

[JLWest]

@Winni

I think that's because he is using test data he made up and not a dataset that has offsets with DST.

[TRon]

Berlin Shows: 21:02
Germany is now: 20:02

Yes, I know 

I quote user Handoko

I quickly generated the time zone data and saved it in Cities.txt. I use TStringList's LoadFromFile and name-value pair features. It is a quick solution. But if you think it should use a database, just do it and change the related code.

So, that could not have been what user bytesbytes meant ?

If the wrong DST/UTC offset is bothering someone then you can simply fix that by editing cities.txt and correct the values manually

I am working on a more robust/satisfactory solution, which is already working for me but I need to fix some loose ends (and am actually quite busy doing other things atm).

[winni]

Hi!

Tron wants to change now the timezone of Berlin. And at the end of October  change it back???

The secrect is called daylight saving. That is the error because it is not taken in account.
There is a up-to-date table needed with the used timezones and if there is daylight saving.
And the algorithm for starting and ending.
A lot of countries do their own stuff (Chile, Israel, USA,...)

The law (!!)  for EU is:
ds start: last Sunday in March, 1:00 UTC
ds end: last Sunday in October, 1:00 UTC

[That it not ending in September anymore is a gift of Maggie Thatcher.
This is the only positive one can say about her]

And there are always changes in the daylight saving:
Russia and Turkey abolished it in the last years.
USA stopped the confusion: All Coutries start and end at the same day.
Except Arizona (Hello JLWest)

And in Canada Quebec has ds but only west of -63° longitude ....

Winni