See what happens if you select same timezone than your local time.
In my previous posts, I already mentioned:
- I quickly generated the time zone data (which I wasn't sure they were correct)
- I do not have solution for time zone calculation (because I didn't follow the previous discussions)
- v0.2 used a fake time calculation
And honestly, it was my first time to learn what daylight saving is from my pm with winni. The v0.2 did not take daylight saving into account.
But the most serious problem is, if you look into the DataSync.pas there is no code to get the computer's time zone. That means it will treat the user time zone as GMT +0.00.
It's just version 0.2, many things haven't implemented yet. And as far as I know, TRon is now working on the database and synchronization. It should be working correctly on version 1.0.
Draw a line ( a hand).
No, I do not want to use line drawing. I knew it fast but it doesn't look good. You will understand why if you see the version 0.3, which I'm still working on.
The first things came into my head when I hear a community clock project:
- It should look good
- Can run on wide range of environments and hardware
- Others can study the code easily
It is a community project, it should not look amateurish. Lazarus/FPC has cross compile ability, the program should be able to run on different OSes, hardware and even old machines. I like KISS concept and I want others to be able to study the code easily. That's why I put many comments inside the code and it is written using traditional procedural style. I know many novice programmers can understand procedural approach easier than OOP style. If it were my own project, I would write it in full OOP approach.
On a PC it is useless and consumes a lot of RAM.
I already mentioned on previous post, in case you miss it. It had a memory leak issue on v0.2. It has been fixed on v0.3. Memory usage is highly depended on the form size. My my test on 1920x1080 full screen, the memory usage CATWW v0.3 never reaches 140 MB.
Why it is slow and need much memory?Hey, now is 2020 do you think we should program a clock that looks like the one 3 decades ago?
Line drawing is fast but they looks jaggy. Antialiased lines are better, with a bit sacrifice of performance. But instead of using drawing functions, I use image scaling and rotating. Unfortunately scaling and rotating is expensive especially on non-hardware-accelerated engine.
The clock painted is using 4 layers of images:
- The background
- The hour hand
- The minute hand
- The second hand
Also if user choose to show 6 clocks, that will be repeated six times.
To make it faster, I use cache. It greatly improves the performance. But a problem happens when resizing the clock. If user resize the clock (by resizing the form), all the caches will need to be refreshed. That why it has performance drop when resizing.
So, I implemented a new trick: runtime-generated multi-resolution image. When refreshing the cache, it chooses the nearest larger images. The more resolutions prepared the more performance improved when resizing.
I did some research, nowadays many users use 1920x1080 resolution or more. On my test, 1200x1200 is the best for the clock images even running it on a large screen. Keeping such huge images in memory consumes a lot of memory. If I choose to prepare 20 different resolutions, it will greatly improve the performance. But for memory friendly, CATWW v0.2 only uses 5 different resolutions: 1200, 1000, 800, 600, 400.
Do you know how much images need to be generated for simply 5 different resolutions? Not 5, but 5 x 4 = 20 images.
The caching system and multi-resolution image concept explain why it requires a lot memory. But memory is cheap, I think it's okay.