Leaderboard

In some occasions the inaccuracy of Delphi's TTimer cased serious headaches so I did some digging and found an old post on how to turn a thread into a much more accurate timer. While I analyzed the code to find out how it works I made some comments and also took the liberty to change it here and there... and wrapped the whole thing in a TComponent which easily can be installed in the IDE and dropped on almost anything. The TThreadedTimer's OnTimer event runs in the VCL thread so any UI element can be manipulated from there. It is also a drop-in replacement for TTimer, meaning you change your DFM and PAS and it should work exactly the same way. My version delays enabling the thread so it won't spin freely until it has an event handler, properly resets the timing sequence if the Timer is set to Disabled and then Enabled again and also - in theory - the OnTimer event will no longer fire during destruction. Being a Windows-only guy it relies on WinApi, but I guess it can be made cross-platform by using Delphi's own TEvent class... as it yields zero benefits I didn't care to look into it. As the original idea wasn't mine the right thing to do is to release this version under the do-whatever-you-want license. Feel free to use, point out possible issues or modify it to fit your needs. God bless open source 🙂 uThreadedTimer.7z

Just remember such hacks could break if compiled with RTL that has another layout. Besides this, the solution is quite OK. However, if at least one of 3rd parties you use accepted raw pointers, the issue wouldn't exist at all.

I have been able to make the GR32-resampling as fast as mine unthreaded, by making some simple changes to the procedure GR32_Resamplers.Resample (in Implementation-part): changing the order of X- and Y- loop in the filling of the horizontal buffer, avoiding jumps in the bitmap-memory, using pointers to walk along the arrays, turning on compiler-optimization for the procedure (biggest improvement) If you want to see for yourself, in the attachment are 3 changed .pas-files that need to overwrite the corresponding ones in the Algorithms-folder under Bitmap Scaling. Renate Bitmap Scaling-Diff.zip

I managed to create a workaround for this. See code below. The mainmenu of the form can be re-initialized by calling "menu.rebuild" . It works best if this is done ~100 ms after the form is re-scaled to the new dpi. type tMenuItemHack = class helper for tMenuItem procedure RebuildMenu; end; tMainmenuHack = class helper for tMainmenu procedure Rebuild; end; procedure tMenuItemHack.RebuildMenu; begin menuchanged(True); //"Protected" method end; procedure tMainmenuHack.Rebuild; var cnt: Integer; item: tMenuItem; begin cnt := items.Count; if cnt > 0 then begin item := items[cnt-1]; item.RebuildMenu;// trigger "menuchanged(True)" on rightmost item (minimize flicker) end; end;

Only when you compile with packages.

I see nothing wrong with using absolute in this case, however you could make it a tiny bit stronger by placing it all in a class and hiding the storage. Maybe use TList as a starting point, but add accessor methods to fetch/append/insert/delete for each type. Keep a state variable so you know what mode its in and only have to switch modes when you change. Also, keep counts for each supported type so you can set the length appropriately. The list would always be an array of integers behind the scenes, but it then could contain an odd number of bytes or words. A ForEachByte or ForEachWord routine could be coded to use a stack to set and reset the state variable if necessary. I have done something similar with absolute when I needed to compare large blocks of data. An integer compares or moves at just short of 4x as fast as looping through 4 bytes. Disclaimer: This doesn't mean you should use this technique because you can. Its good practice to always measure to find the real bottlenecks and not add complexity to optimize when the net result is still nearly identical.

@John van de Waeter I confirmed the problem. I reported it on GitHub, you can follow it there: https://github.com/skia4delphi/skia4delphi/issues/94