dummzeuch

Yes, that's another option. The most likely outcome will be fragmentation though. Instead of one mostly dead project, there will be several, most of them dead ends, and any prospective users or contributors will wonder which one to use. Moving the project anywhere else won't solve that, though. There are many dead projects on e.g. github too. Unless of course somebody takes up the burden of maintaining the project, which I think is rather unlikely.

There are two options: Contact Lars Dybdahl, the official maintainer Send these patches my way and I'll have a look and possibly commit them to sourceforge (as far as I know I am the only one left who has write access there, but I have no admin access). By now even the official dxgettext website dxgettext.po.dk no longer works (at least my browser gets redirected to delphi.dk which then only shows an error), it looks as if the project is even more dead than it used to be. Also, I haven't heard from Lars for a long time. So sending them to me is probably the option with the best prospects of success.

Hm, interesting. I didn't even know this is possible. At a first glance Delphi 2007 doesn't look too bad on a 4K monitor with scaling set to 125% or even 150%. (GExperts has has some problems though). Unfortunately this seems to be a global setting for the executable rather than a setting for a shortcut only which makes it a lot less useful.

It will probably work much better for this use case than for the IDE, because you can simply fix the source code rather than trying to patch the executable at runtime. I guess you are aware that instead of setting the Windows compatibility options for an executable you can simply add a manifest to your executable that tells Windows it is HighDPI aware?

It was fun playing around with this, but the result is a bit disappointing once you get over the first "wow, it works". Just in case anybody else wants to have a go, here is the result of the last two days of "work". Note that the source checks whether Application.ExeName is 'hbds.exe' to decide whether to install the wizard or not. To get this to work, you will either have to remove that check or copy the bds.* files in the Delphi 2007 bin directory to hbds.* and of course set the Windows compatibility options for that hbds.exe rather than for bds.exe . It will add a new menu "High DPI" to the IDE's main menu with two entries "patch" and "un-patch" which should be self explanatory. Have fun, but remember: I will not fix your computer if you break it. 😉 @Attila Kovacs thanks for that idea which was quite fun to play around with. Take whatever you can use from the attached sources. Delphi2007HighDpi.zip

Yes, this seems to work, even when reading it and setting it to the same value. It also makes the OnMeasureItem event redundant. (edit: No that event is still necessary.) That solves the problem for the tree view, but unfortunately not for the TVirtualTreeViews used in grid mode (e.g. the message window or the breakpoint list). There even setting the font size does not make any difference.

If you have got more than one monitor with different DPI settings, it makes all lot of sense to change the IDE scaling on the fly. Just imagine moving a window from a 4K monitor with 150% scaling to a HD monitor with 100%. (And guess who has got such a setup...)

uses TypInfo; function TAdvancedObject_SetIntProperty(_Instance: TObject; const _Name: string; _Value: Integer): Boolean; var PropInfo: PPropInfo; begin PropInfo := GetPropInfo(_Instance.ClassInfo, _Name); Result := Assigned(PropInfo) and (PropInfo.PropType^.Kind = tkInteger); if Result then TypInfo.SetOrdProp(_Instance, PropInfo, _Value); end; // called as TAdvancedObject_SetIntProperty(AComponent, 'DefaultNodeHeight', FVtNodeHeight);

No idea. But I guess they would have overriden if that was necessary.

If it is overridden, the correct method should automatically be called. If it is reintroduced, that's bad practice, in particular for such an important base method, and I doubt that any Borland/Codegear developer did this in the code of the IDE.

TControl.Invalidate is virtual, so this should call the correct method of any derived class. I'll post the RTTI code tomorrow when I'm back at my computer. It's actually quite simple and will work with any relevant version of Delphi, as long as the property is declared published.

This is not an Access Violation.

That's what I meant by: Oddly enough changing the font size takes effect immediately but still ignores the change to DefaultNodeHeight until I click on a tree node. And even then it only redraws that one tree node and the one that was selected previously.

I am seeing two problems: Simply setting the DefaultNodeHeight does not make any difference, regardless whether I use your hack or simply set it via RTTI. When also assigning an OnMeasureItem event (via RTTI) that returns the correct node height, it works, but only when I click on an entry which causes that entry to be redrawn or when I load a new project. I tried to call TWinControl.Invalidate and sent a WM_Paint message to it but it didn't make any difference. I have also temporarily disabled all experts which did not make any difference. There is one difference between what your expert did and what I am currently trying: I want to have menu entries to turn this functionality on and off. I also want to make it use the "correct" size depending on the current DPI and the design DPI.

As you might have guessed I am playing around with this code. It works fine for the object inspector (I have added code to also increase the font size). But it does nothing for the TVirtualTreeViews e.g. the Project Manager. As far as I understand it, it should set the DefaultNodeHeight by directly calling some method whose address is hard coded as you wrote above. My installation should contain all patches, but it doesn't work. How did you determine that address? Edit: I also tried to set the DefaultNodeHeight property via RTTI. It also didn't make any difference. But in the IDE Explorer the correct value was shown.

As for having the option to start with or without high DPI awareness: I just copied the bds.* files in my Delphi 2007 bin directory to hbds.* and created an entry for that under HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers for it. Now I can start the IDE as bds.exe with System High DPI settings and hbds.exe with Application High DPI settings. I also tried to simply edit the application manifest of hbds.exe but that didn't work, unfortunately. Not sure whether this will work with newer IDEs though, because Embarcadero "improved" their detection of tampering with the licensing.

Just in case anybody else is interested: The setting @Attila Kovacs was talking about is stored in the registry: HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers There are entries with the full path of the executable. In my case for Delphi 2007: C:\Delphi\Delphi2007\bin\bds.exe And a text value. which seems to contain entries separated by a space. Enabling the "High DPI scaling override" option adds a "HIGHDPIAWARE" value to that entry, Disbling it removes that entry I'm not sure where the selection from the combo box is stored though. Possibly under HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store There are again entries with the full path of the executable, but this time the data is binary so it's not easy to decode. All entries start with the letters SACP, whatever that means. EDIT: No, changing that option did not make any difference there. The selection in the combo box decides what is stored there too. Enabling the "High DPI scaling override" option and selecting "Application" adds a "HIGHDPIAWARE" value selecting "System" adds a "DPIUNAWARE" value selecting "System (enhanced)" adds "GDIDPISCALING DPIUNAWARE" Disabling it removes these values. As the entries refer to the absolute path of the executable rather than the shortcut, there seems to be no way to create separate entries for different shortcuts to an executable which is a bit inconvenient. Maybe we should move this part of the conversation to a new thread? "Making older Delphi IDEs partially High DPI aware" or something?

I don't remember that. I probably was busy at the time and then forgot about it. Did you file (a) bug report(s)?

No, that doesn't make any sense. Even assuming you meant the the other way round: ExtractFileDrive(ExtractFileName(ExeName)) it wouldn't return what he wants. I'd go for ExtractFileName(ExtractFileDir(ExeName))

Oh, you were referring to how the program decides how many threads to use? I have implemented that already to use as many threads as there are logical processors, determined using GetSystemInfo. I was more worried whether their current computers are good enough to run the program or if they need an upgrade. If their hardware changes in the future, it will be likely become faster anyway.

I've taken the low tech approach: I asked the colleagues, what type of processor their computer(s) have.

Interesting approach. I already do that. Hm, yes. I'll have to think about this. So far I am quite satisfied with reducing the analyzing time for the pictures by a factor of 8 (on my computer). Now I need to find out how many logical processors are available on the computers on which this program will actually be used. Since these are probably >2 years old, they might need updating anyway. The program itself now has 60% processor usage, up from 17% (when it was single threaded), so there are probably some other parts which could be improved which might be easier to achieve.

Of course: There are only 8 virtual processors on my computer, so the maximum of threads that can run in parallel is 8. I should have thought of that.

My knowledge of processor architecture is insufficient to answer this question. The work packages are advanced records in a dynamic array, so their data is located within the same memory area on the heap. Which turned out to be the problem. The work memory area of each work package was declared like this: TWorkPackage = record FCounter: PInt32; FIsDone: LongBool; FScanLine0: PByte; FBytesPerLine: Integer; FWidth: Integer; FHeight: Integer; FTop: Integer; FBottom: Integer; FPixelValues: TMedianValuesArr; FMedianPixelArr: TMedianPixelArr; FArr: TBrightnessMatrix; FSum: int64; FStopwatch: TStopwatch; end; And these were stored in a dynamic array, so they were all located within the same memory area. FMedianPixelArr is constantly being written to in all threads. If I understand the cache line stuff correctly, the fact that these records were stored all within a memory block smaller than the CPU cache line (apparently 256 Bytes at most with current CPUs) this caused the cache becoming invalid for all threads every time one of the threads wrote to this area. For testing this, I have now simply increased the size of the record by 256 bytes by adding an array [0..255] of byte to it so each of them is larger than the maximum possible cache line. Here is the timing after this change: 1 calls using 1 threads: 1143 ms (TotalTime [ms]: 1125 SingleTimes [ms]: 1125) 1 calls using 2 threads: 607 ms (TotalTime [ms]: 1124 SingleTimes [ms]: 565 559) 1 calls using 3 threads: 451 ms (TotalTime [ms]: 1186 SingleTimes [ms]: 395 393 398) 1 calls using 4 threads: 368 ms (TotalTime [ms]: 1222 SingleTimes [ms]: 308 298 312 304) 1 calls using 5 threads: 367 ms (TotalTime [ms]: 1357 SingleTimes [ms]: 244 306 303 242 262) 1 calls using 6 threads: 344 ms (TotalTime [ms]: 1533 SingleTimes [ms]: 228 259 274 271 245 256) 1 calls using 7 threads: 296 ms (TotalTime [ms]: 1636 SingleTimes [ms]: 222 246 227 219 236 250 236) 1 calls using 8 threads: 304 ms (TotalTime [ms]: 1806 SingleTimes [ms]: 226 222 224 225 227 225 224 233) 1 calls using 9 threads: 322 ms (TotalTime [ms]: 1909 SingleTimes [ms]: 230 226 198 238 220 197 199 195 206) 1 calls using 10 threads: 326 ms (TotalTime [ms]: 2009 SingleTimes [ms]: 174 216 172 208 176 236 232 178 213 204) 1 calls using 11 threads: 295 ms (TotalTime [ms]: 2140 SingleTimes [ms]: 232 222 221 165 221 171 201 162 158 181 206) 1 calls using 12 threads: 273 ms (TotalTime [ms]: 2494 SingleTimes [ms]: 212 208 224 210 227 210 212 212 198 202 198 Which is exactly what I would have expected: The total processing time is reduced roughly inverse proportionally with the number of threads until the overhead of splitting the work reduces the potential gain of using more threads. Hm, looking at the single times values: Given that with each additional thread the number of lines each thread needs to be processing decreases, I wonder why these times don't get any lower than around 200 ms. Anyway, thanks @Anders Melander you seem to have nailed the problem.