Yaron

I did write "gaffs" and if there was an actual solution that would have been very welcome, but I assumed than there may not be one. I actually didn't find a better forum section to post this.

I tried, unfortunately it didn't help. It's actually very strange in how it presents itself, it's not that it's out of sync, it's not showing debug points on the first 7000 lines of code and then the next 12000 lines seem to synch correctly.

I don't really care, I just found it funny in this particular context where the first function line sets the result value and D7 warns it's not set.

I know this is touching on archeology, but Yes, I'm still using Delphi 7 to develop Zoom Player, transitioning is hard. Take this post as semi-comical, I'm not really complaining, just sharing the joy. However, if you can think of something I haven't, that would be cool of you. This issue is pretty much cosmetic, but check this out: https://imgur.com/a/QA1l8iX A warning about return value of a function where the first line of the function sets the return function. Any ideas? I have another amusing case where a unit's source code and debug points don't match, Zoom Player's Options dialog. You're probably thinking to yourself "He's lazy, this is a common issue, he probably pasted some unicode character into the code" or "One of the text lines is using a linux style LF instead of Window's CRLF", but no, I tested for this thoroughly. My suspicion? Zoom Player's options dialog is over 19K lines of code and contains 2279 components. I guess back in the days of 2002, this sort of component use was unexpected.

If I'm going to that level of detail in the code itself, I can write it myself. This is a form of benchmark for me, a nice to have feature that isn't killing me right now as there are alternatives (e.g. using libVLC media engine).

Possibly, but soon (12-18 months) one of these AI models will be able to do it close enough that I can make it work and I can wait, I have other more important features in my work-queue. For now this is my personal benchmark for AI's coding capabilities.

I have a need for a very specific feature I'd like to add to Zoom Player, an HTTP caching bridge. The purpose of an HTTP caching bridge is to cache repeated HTTP "GET" queries generated by DirectShow media streaming filters (components) such as LAV Filters when streaming mp4/mkv files from media servers such as PLEX, Emby or Jellyfin. Caching is required as these components treat streaming files the same as local files with repeated seeking to read headers and frame indexes, degrading performance (very slow seeking, long pauses when switching subtitle tracks, etc) and unnecessarily overloading the media server. Since the HTTP caching bridge is a 100% self-contained feature, I thought AI would be well suited to the task. I wrote a very detailed design document and fed it into every AI system I had access to and asked the AI to implement the project goal (a section in the design document). I wrote about my experiences trying to get various AI models to do the job and included the design document at the end of the post: https://www.reddit.com/r/ZoomPlayer/comments/1m0fy46/ai_and_an_http_caching_bridge/ Has anyone managed to get AI to code anything like this level of complexity?

The standard Delphi TComboBox is based on WinAPI. Every item you add to the list triggers a WinAPI "SendMessage" call, which takes much (x100) longer than adding an item to a TStringList. To overcome this delay, with the help of AI, I designed a slimmed down replica of TComboBox based on TStringList: https://github.com/bLightZP/ZPComboBox If you have a form with lots of TComboBox drop down list components and it's not opening fast enough for you, try this. Limitations The only event supported is OnChange. The only style supported is csDropDownList. The pop-up listbox is shown in a pop-up window, so the underlying window's title bar changes color when losing focus. The styling is close to TComboBox, but not identical.

Interesting, let me know if you figured out how to use a layered window as a child under Delphi 7.

TComboBox is a wrapper for a WinAPI component. When you call ComboBox.Items.Add, it triggers a WinAPI SendMessage call, which is very very slow (relative to a standard TStringList.Add), I wrote about it here if you're interested: https://www.reddit.com/r/ZoomPlayer/comments/1iu0lm3/low_level_code_optimization_or_how_i_made_zoom/

This doesn't solve the performance issue. TComboBox is inherently slow because it uses SendMessage for every item you add.

I'm using a layered window to do a transparent UI effect over video, but as far as I know, you can't do the glass effect in hardware using standard WinAPI, I believe you have to use the composition API for that (is it still considered WinAPI?). If no video in the background then it's simple enough to use GDI+ to create an anti-aliased round rectangle (I have pure pascal code to do it, but it's slower), Gaussian blur copy from the background image on paint, etc. You'd also have to intercept the hittest message to allow resizing/moving of a borderless window.

I designed an open-source (MIT license) TComboBox replacement that's not based on WinAPI: https://github.com/bLightZP/ZPComboBox My software (Zoom Player) uses a similar options dialog design to your own and using this component cut the form's create -> show time in half. P.S. I see you're using TTreeView, if you're restoring the last TreeView selected item when the form opens incorrectly, it can incur ~700ms penalty, something worth checking out.

You can do this using DirectShow, but as far as I know, there is no DirectShow filter (component) that can load from a TStream, you would have to write one yourself or use an AI to write one for you. I believe there are sources for the "File Source Async" DirectShow filter, you can use that as a base, replacing the disk IO with TStream commands. But it will be much easier to write the stream to a file in a temp folder and then play it.

Beyond what you're already using, there is a slight speedup trick of setting the TComboBox's style to "csSimple" when adding the items and then restoring the style afterwards. And since you're inserting the same data into the controls, might be slightly faster to do it only once, keep a pointer to the first object and then just do Assign on the items. But I'm afraid the speed difference between adding items to a TStringList compared to a TComboBox is ridiculous and it might just be better to write a replacement component (which I'm currently investigating).