Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Yaron last won the day on November 7 2020

Yaron had the most liked content!

Community Reputation

50 Excellent

Technical Information

  • Delphi-Version
    Delphi 10.3 Rio

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The code I'm calling is very thread-unsafe, I would have to completely rewrite several sub-systems to make it thread safe, I think it would be more beneficial if I could somehow instantly synchronize the code. Thing is, how does synchronize work, is it only triggered on a system tick? If so, I'm stuck at again at the 16ms tick timing and this whole approach is pointless unless I rewrite a lot of code. I discovered a few things regarding timeBeginPeriod : 1. From MSDN: "Prior to Windows 10, version 2004, this function affects a global Windows setting. For all processes Windows uses the lowest value (that is, highest resolution) requested by any process. Starting with Windows 10, version 2004, this function no longer affects global timer resolution. For processes which call this function, Windows uses the lowest value (that is, highest resolution) requested by any process. For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution." 2. timeBeginPeriod doesn't work as advertised. If i use timeBeginPeriod(16), you'll get the usual 16ms timer accuracy, however, at least on my system (fully patched win10), calling timeBeginPeriod(15) is enough to set an actual timer accuracy of 1-2ms. So if I can't find a way to synchronize callbacks without changing periodic timer accuracy, I believe using timeBeginPeriod with tthread/Sleep/synchronize is the safest approach I can use.
  2. According to the GitHub sample I linked above, "The stdcall [callback] procedure will be called for each interval for each and every timer in the queue. In other words, you can expect this event to be called by multiple threads and it needs to be completely thread safe". So this brings up my previous question, how can I synchronize the actions I want to take with the main thread?, otherwise my code will not be thread safe.
  3. I can't use the GPU, it would mean rewriting A LOT of code and in my use-case I actually prefer the GPU to be free to do other things. Does anyone know if the callback function in CreateTimerQueueTimer runs within my app's main process thread or in a completely different thread? If it's in a different thread, how do I synchronize the call to make sure it's running in the main thread? Using critical sections or is there another mechanism I'm not thinking of?
  4. I don't care about wasting resources while there's screen updates to generate, I'm concerned about wasting resources when doing nothing but waiting for the next update. Trying to work with v-sync is a pain, if you miss an update window there's serious judder.
  5. I found a good resource at https://github.com/grijjy/DelphiTimerQueue Hopefully it will resolve my issue, the workaround I'm currently using is having multiple thread that keep trying to update the screen if at least 1ms passed since another thread triggered an update. Not really the best approach.
  6. I don't want to block for v-sync, I don't care if there's tearing. I just want to get 60+fps screen updates without bogging down a CPU core. I'm looking at queue timers as FPiette mentioned (looks like multimedia timers were depreciated in favor of queue timers), if anyone has a sample using "CreateTimerQueueTimer" in Delphi (compatible with Delphi7), that would be cool.
  7. The problem is not the frame-update speed (which on my PC is about 3ms), it's about how to time the call to update the screen within a specific time-frame and not in 16/32ms intervals.
  8. I want smooth scrolling, using Sleep(1), I measure 15-30ms delay per frame, resulting in unstable scrolling because the delay between screen-updates is inconsistent/juddery and ~33fps which looks really bad.
  9. I have a function I'd like to call 120 times per seconds using TThread.Synchronize (as the function updates the screen). I don't want to completely bog down a CPU core by constantly calling "QueryPerformanceFrequency" in a loop until the time is right to trigger the function. I originally envisioned using Sleep(1), but in reality, Sleep(1) usually means 15.6ms unless I change the entire system's Tick accuracy using "TimeBeginPeriod/TimeEndPeriod". However, I don't want to affect the entire system as I've read there's a harsh 25% battery impact when switching the accuracy and I don't want to drain the client's battery. So what is the best, most precise way to time/trigger synchronized calls from a thread?
  10. Yaron

    Issues with Sleep(1) called in a loop

    Nevermind, I replaced Sleep with WaitForSingleObject and used an event to break out of the wait when closing the dialog.
  11. I use a thread to update an animated 'please wait' dialog while doing other things in the background. The issue is, I want to be able to dismiss the please wait dialog instantly and since I use animations, I use "Sleep" commands to to time the animation and take minimum CPU time. However, for some reason, doing Sleep(10) returns a vastly different result than calling For I := 0 to 1 do If Terminated = False then Sleep(5); which for some reasons takes ~30ms to complete. For reference, calling For I := 0 to 9 do If Terminated = False then Sleep(1); takes ~150ms. My problem is with Delphi 7, but I doubt it's specific to this version of Delphi, any ideas?
  12. No, I don't use TJPEGImage at all, I'm basically compositing several tbitmaps, writing a bit of text on an image and using 'fill' to draw a small box (for Zoom Player's media library thumbnails), The canvas are all locked and the issue only seems related to brush colors.
  13. I ended up writing my own bitmap based fill function, since it has a lot less overhead (my code needs less sanity checks as the input values are always in valid ranges), it's about 40% faster than Delphi's implementation, so win-win. Although I resolved the issue, if anyone knows the "recommended" method of using brushes with threads, I'd be interested.
  14. @David Heffernan The entire threaded code is written within the canvas's lock section and works without any issues (font drawing and bitmap operations), except for the brush color which occasionally seems to use the wrong color. I didn't paste the entire code for simplicity.
  15. Looks like I have to raise this thread from the dead. Even though I'm calling Bitmap.Canvas.lock and no other thread is writing to the canvas, I rarely get a weird fill color issue. This is a subset of the code: WorkBM.Canvas.Lock; Try WorkBM.Canvas.Brush.Color := clRed; WorkBM.Canvas.FillRect(barRect); Finally WorkBM.Canvas.Unlock; End; Somehow, the fillrect colors occasionally (very rarely) swaps to a different color. Do brushes require a separate type of lock?