Forms editor scaling changes across platforms lazarus / 10-Designer ---------------------------------------------------------------------- VTwin · 2019-07-25 12:42 I had a few questions in a thread regarding problems with DPI aware scaling: https://forum.lazarus.freepascal.org/index.php/topic,46183.0.html but thought it might make sense to ask here. If I design a form on a Mac, or in Linux, or on Win32 on XP, the scaling is consistent. For example, I might make PaintBox 20 x 20, and set the anchor spacing between CheckBoxes to 12. If I open the same form in Windows 7, the PaintBox is 30 x 30, and the anchor spacing is 18. I tried turning off all DPI features (see other thread), but it continues to happen. Does anyone else see this happening? Do you know how to turn it off? ---------------------------------------------------------------------- wp · 2019-07-25 13:02 What is the resolution on these systems? ---------------------------------------------------------------------- VTwin · 2019-07-25 14:15 The Mac display is 13.3-inch (2560 x 1600). Windows 7 is running in VirtualBox, and can be set to various scaled resolutions, 1x, 1.25x, 2x, etc. Which one it is does not seem to make a difference in Lazarus's behavior though. That is, I can open a project in any resolution on Windows and Lazarus changes the sizes and spaces inside the lfm file, 20->30, 12->18. This seems to be new behavior since I updated VirtualBox a few days ago, but why is Lazarus changing the lfm file?   A sample project, designed on a Mac, is attached. Please look at the unit1.lfm file in a text editor to verify the sizes 12 and 20. Then open it in Windows Lazarus and see if they change. ---------------------------------------------------------------------- wp · 2019-07-25 14:16 I set up a little demo, out of the box with Laz 2.1/fpc3.0.4 on Win 10 at 96 ppi. All scaling-related project settings are at the installation defaults. Referring to the other thread, the demo shows a string grid plus some other controls. The column widths can  be changed and stored in an ini file. The ini file is read on the OnShow event of the form (OnCreate is too early). In order to make the ini file transferable between systems of different resolutions the stored values are scaled to 96 ppi. I copied the project files (and the ini file) to a VM with Win7 at 144ppi (150%) and to a Linux notebook at 120ppi (qt widgetset). (I do not have access to a Mac). On all these systems the forms look the same, of course magnified according to the screen resolution. Then on each system, I modified the copied form size by a tiny amount and resaved the form so that the new resolution is written to the lfm file. After re-compilation and starting, the scaling ratio did not change and the form looked the same as immediately after import. Therefore, I am sure that you are doing something wrong. But without seeing a sample project I cannot tell you what. ---------------------------------------------------------------------- wp · 2019-07-25 14:29 I found your demo project, activated scaling again (checked LCL scaling) and recompiled under Win 10 at 96 ppi and under Win 7 at 144 ppi. See the attached screenshots. The images look absolutely correct. Of course, with scaling to a higher resolution, say 150% all dimensions must increase by this factor. This is way scaling is done after all. Suppose you have a 26" monitor with, say 2000x1000 pixels (numbers selected for simplicity of calculation). Then you go to a "Super real-life retina display", same size but with 3000x1500 pixels (i.e. 150% more in each dimension. Without scaling a form of 2000x1000 pixels would fill the entire screen on the 2000x1000 monitor, but only part of it on the 3000x1500 model. ---------------------------------------------------------------------- VTwin · 2019-07-25 16:34 Quote from: wp on July 25, 2019, 04:16:39 pmI set up a little demo, out of the box with Laz 2.1/fpc3.0.4 on Win 10 at 96 ppi. All scaling- related project settings are at the installation defaults. Referring to the other thread, the demo shows a string grid plus some other controls. The column widths can  be changed and stored in an ini file. The ini file is read on the OnShow event of the form (OnCreate is too early). In order to make the ini file transferable between systems of different resolutions the stored values are scaled to 96 ppi. I copied the project files (and the ini file) to a VM with Win7 at 144ppi (150%) and to a Linux notebook at 120ppi (qt widgetset). (I do not have access to a Mac). On all these systems the forms look the same, of course magnified according to the screen resolution. Then on each system, I modified the copied form size by a tiny amount and resaved the form so that the new resolution is written to the lfm file. After re-compilation and starting, the scaling ratio did not change and the form looked the same as immediately after import. Therefore, I am sure that you are doing something wrong. But without seeing a sample project I cannot tell you what. Fantastic, thanks! I tried your project on Win 7, Mac, and Ubuntu, and all work very well. I actually may have been on the right track, but did not understand exactly what I was doing. I think I was scaling them up by 1.5 each time I opened the form in Windows, but the scale factor was 1 on Mac and Linux. Storing them at 96 ppi and converting back and forth, as you did, might do the trick. I will give it a go. I also did not understand that Lazarus lfm files were modified according to platform ppi, I thought they were supposed to be platform independent. It alarmed me when I saved one on Windows at 144, and opened it on Mac. I guess that is related to the "Force DPI scaling in design time" option? It seems peculiar that this scaling difference only surfaced when I upgraded VBox, prior to that lfm files reported identical sizes in the Object Inspector on all platforms. Is it possible VBox changed my resolution in Win 7 from 96 to 144? ---------------------------------------------------------------------- VTwin · 2019-07-25 16:42 Quote from: wp on July 25, 2019, 04:29:47 pmI found your demo project, activated scaling again (checked LCL scaling) and recompiled under Win 10 at 96 ppi and under Win 7 at 144 ppi. See the attached screenshots. The images look absolutely correct. Of course, with scaling to a higher resolution, say 150% all dimensions must increase by this factor. This is way scaling is done after all. Suppose you have a 26" monitor with, say 2000x1000 pixels (numbers selected for simplicity of calculation). Then you go to a "Super real-life retina display", same size but with 3000x1500 pixels (i.e. 150% more in each dimension. Without scaling a form of 2000x1000 pixels would fill the entire screen on the 2000x1000 monitor, but only part of it on the 3000x1500 model. Thanks for trying it out, I'm glad it works correctly. Are the "Win 10 at 96 ppi" and "Win 7 at 144 ppi" settings configurable anywhere (in Lazarus, VM, or System)? That is, is it possible to compile "Win 7 at 96 ppi"? I could not find anything, I tried various screen resolutions, but Lazarus always came back at 144. ---------------------------------------------------------------------- VTwin · 2019-07-25 19:13 Not a new problem: https://forum.lazarus.freepascal.org/index.php?topic=29860.0 ---------------------------------------------------------------------- VTwin · 2019-07-25 19:34 Quote from: VTwin on July 25, 2019, 06:42:32 pmAre the "Win 10 at 96 ppi" and "Win 7 at 144 ppi" settings configurable anywhere (in Lazarus, VM, or System)? That is, is it possible to compile "Win 7 at 96 ppi"? I could not find anything, I tried various screen resolutions, but Lazarus always came back at 144. Yes: https://wiki.lazarus.freepascal.org/High_DPI#Windows_Vista_and_Windows _7 I experimented going back and forth between 96 and 144, and Lazarus behaves as wp explained. I understand now, and now know I need to check my applications on different platforms and dpis (at least on Windows). I also will avoid designing at different dpis. And now it is time for a drink. ---------------------------------------------------------------------- wp · 2019-07-25 19:44 Quote from: VTwin on July 25, 2019, 06:34:27 pmI also did not understand that Lazarus lfm files were modified according to platform ppi, I thought they were supposed to be platform independent. It alarmed me when I saved one on Windows at 144, and opened it on Mac. I guess that is related to the "Force DPI scaling in design time" option?When you design a form in Lazarus or Delphi the units are pixels. Therefore, the design depends on the DPI of the system on which it was created or saved. But there is a property DesignTimePPI which is written to the lfm file and tells the LCL whether scaling routines need to be applied. So, when you design a form which is 400x200 pixels on a 96 ppi system the IDE knows that these pixel values are valid only for 96 ppi. When you copy the form files to and open them on a system at 144 ppi (150%) the IDE knows that itself is running at 144ppi, but the file is for 96 ppi. Therefore all lengths are multiplied by 1,5 (=144/96). When you now save the file on the high-dpi system the new length values are written, but also the new DesignTimePPI. if you open the form on the high-dpi system a second time no more scaling will be applied because the DesignTimePPI and the PPI of the IDE are matching. I never touched "Force DPI scaling in design time", but I guess that it breaks this mechanis. I would not recommend to change this setting unless you know exactly what you are doing. Quote from: VTwin on July 25, 2019, 06:34:27 pmIt seems peculiar that this scaling difference only surfaced when I upgraded VBox, prior to that lfm files reported identical sizes in the Object Inspector on all platforms. Is it possible VBox changed my resolution in Win 7 from 96 to 144? I don't think that the version of the VirtualBox has anything to do with the resolution of the guest operating system. Maybe you changed something incidentally. ---------------------------------------------------------------------- wp · 2019-07-25 19:55 Quote from: VTwin on July 25, 2019, 09:34:29 pmQuote from: VTwin on July 25, 2019, 06:42:32 pmAre the "Win 10 at 96 ppi" and "Win 7 at 144 ppi" settings configurable anywhere (in Lazarus, VM, or System)? That is, is it possible to compile "Win 7 at 96 ppi"? I could not find anything, I tried various screen resolutions, but Lazarus always came back at 144. Yes: https://wiki.lazarus.freepascal.org/High_DPI#Windows_Vista_and_Windows _7 This (self-)answer is unclear: does the "Yes" refer to the first part or the second part of the question? My answer: You cannot configure Lazarus to use an arbitrary PPI value. The LCL always (?) uses the value defined by the operating system. On Windows 10, go to "System settings" > "System" > "Display". Under "Scaling and Layout" there is a combobox with the values "100% (recommended)", "125%", "150%, "200%" - this percentage refers to the PixelsPerInch of the system, i.e. 96ppi, 120ppi, 144ppi, 192ppi. (Note: I using a German Windows system, the mentioned words may be translated incorrectly). On Windows 7 right-click on the desktop and select "Display" from the context menu (IIRC). This PPI value is a system-wide setting which affects every program. ---------------------------------------------------------------------- VTwin · 2019-07-25 20:12 Quote from: wp on July 25, 2019, 09:55:02 pmQuote from: VTwin on July 25, 2019, 09:34:29 pmQuote from: VTwin on July 25, 2019, 06:42:32 pmAre the "Win 10 at 96 ppi" and "Win 7 at 144 ppi" settings configurable anywhere (in Lazarus, VM, or System)? That is, is it possible to compile "Win 7 at 96 ppi"? I could not find anything, I tried various screen resolutions, but Lazarus always came back at 144. Yes: https://wiki.lazarus.freepascal.org/High_DPI#Windows_Vista_and_Windows _7 This (self-)answer is unclear: does the "Yes" refer to the first part or the second part of the question? My answer: You cannot configure Lazarus to use an arbitrary PPI value. The LCL always (?) uses the value defined by the operating system. On Windows 10, go to "System settings" > "System" > "Display". Under "Scaling and Layout" there is a combobox with the values "100% (recommended)", "125%", "150%, "200%" - this percentage refers to the PixelsPerInch of the system, i.e. 96ppi, 120ppi, 144ppi, 192ppi. (Note: I using a German Windows system, the mentioned words may be translated incorrectly). On Windows 7 right-click on the desktop and select "Display" from the context menu (IIRC). This PPI value is a system-wide setting which affects every program. Thanks. Sorry to be unclear. I meant, yes, 'it possible to compile "Win 7 at 96 ppi"'. The link is to instructions to change the Windows system setting. Your answer is clear. On Windows 7 (at least my version) it is under "Control Panels" > "Display" > "Set Custom text size (DPI)". This gives the same options that you list. I tried Lazarus at 96 and 144, and now understand how it behaves. Thanks for your help. ---------------------------------------------------------------------- VTwin · 2019-07-25 21:43 @wp I modified my programs to save column widths at 96 dpi, and converted back and forth to form resolution, as you suggested. I did the same with Form widths and heights. The form left and top are saved at form resolution. Lazarus scaling and DPI aware are turned back on. Tested on Mac 96 dpi, Linux 96 dpi, and Windows 144 dpi. So far everything is working great. Many thanks. ---------------------------------------------------------------------- kupferstecher · 2019-07-25 22:09 Quote from: wp on July 25, 2019, 04:29:47 pmOf course, with scaling to a higher resolution, say 150% all dimensions must increase by this factor. This is way scaling is done after all. Suppose you have a 26" monitor with, say 2000x1000 pixels (numbers selected for simplicity of calculation). Then you go to a "Super real-life retina display", same size but with 3000x1500 pixels (i.e. 150% more in each dimension. Without scaling a form of 2000x1000 pixels would fill the entire screen on the 2000x1000 monitor, but only part of it on the 3000x1500 model. If scaling is activated, then yes. But seems Lazarus also scales the design time form if scaling is disabled in the settings (using Laz 2.0.2). I.e. if I design a form under Win 7 125% with disabled scaling and I change dpi-settings of Windows to 100% then the form will be much smaller. On the same time a form designed and compiled under a dpi-settings will stay in the original size no matter under which dpi- setting the Exe is run. The paradigm 'Write once, compile everywhere' is broken for disabled dpi scaling (and backward compatibility as well). Can someone comment on that? I may be wrong as I'm not familiar with dpi-scaling yet. ---------------------------------------------------------------------- VTwin · 2019-07-25 22:33 @kupferstecher That was my concern. I was not able, and it appears not possible, to turn off scaling in Lazarus. It is determined by the system dpi, as explained by wp. It appears dangerous to edit the same project on systems with different dpis. A fly in the ointment for 'Write once, compile everywhere'. At least now that I understand what is going on, I can deal with it. My plan at the moment is to initially debug on systems with 96 dpi, and then do some testing on Windows at 144 or other resolutions. ---------------------------------------------------------------------- kupferstecher · 2019-07-25 22:50 Does a compiled Exe have the original size for you on different dpi- scalings? So design behaviour (always scaling) and runtime behaviour (scaling only if enabled) is different? ---------------------------------------------------------------------- wp · 2019-07-25 23:06 I'll have to check the unscaled behavior tomorrow. Although I don't understand why somebody might want to turn scaling off... Quote from: VTwin on July 26, 2019, 12:33:08 amIt appears dangerous to edit the same project on systems with different dpis. I've done it many times, no problems. (But of course, i always have LCLScaling enabled). ---------------------------------------------------------------------- VTwin · 2019-07-25 23:18 My initial test shows that an application compiled on Win 7 at 96 dpi does not display correctly on Win 7 at 144. That is with DPI options on. Happy to be proved wrong. I note also that compiling a form designed at 96 requires a change, even a small one, to a form to get it to recompile and display correctly at 144. ---------------------------------------------------------------------- VTwin · 2019-07-25 23:21 Quote from: wp on July 26, 2019, 01:06:27 amI'll have to check the unscaled behavior tomorrow. Although I don't understand why somebody might want to turn scaling off... Quote from: VTwin on July 26, 2019, 12:33:08 amIt appears dangerous to edit the same project on systems with different dpis. I've done it many times, no problems. (But of course, i always have LCLScaling enabled). Fair enough, that is good news. It only happened to me when I unchecked the "Force DPI scaling" option. Hopefully it is safe otherwise. ---------------------------------------------------------------------- wp · 2019-07-25 23:21 Quote from: VTwin on July 26, 2019, 01:18:19 amMy initial test shows that an application compiled on Win 7 at 96 dpi does not display correctly on Win 7 at 144. That is with DPI options on. You mean: you compile an application on Win/96dpi, copy the exe to a system at 144dpi, and it does not scale correctly although high-dpi was active during compilation? I just re-checked this procedure with the demo that I posted earlier in this thread. No problem, the copied form looks exactly like the one compiled on the 144dpi system. ---------------------------------------------------------------------- wp · 2019-07-25 23:32 Quote from: VTwin on July 26, 2019, 01:18:19 amI note also that compiling on Win 7 at 144 requires a change, even a small one, to a form to get it to recompile and display correctly at 144. I don't think that this is essential: with the tiny change a new lfm is written on the 144dpi system and it contains the new dpi value. When this file is opened on the 144dpi system next time, no conversions have to be executed because the dpi values are matching. Without a change the lfm is not written to disk at all even if you changed code in the pas file, but this means that the lfm still contains the old dpi value. When the project is opened the next time on the 144 dpi system scaling should occur due to the different dpi values. ---------------------------------------------------------------------- VTwin · 2019-07-26 00:02 Quote from: wp on July 26, 2019, 01:21:59 amYou mean: you compile an application on Win/96dpi, copy the exe to a system at 144dpi, and it does not scale correctly although high-dpi was active during compilation? I just re-checked this procedure with the demo that I posted earlier in this thread. No problem, the copied form looks exactly like the one compiled on the 144dpi system. That is what I did. I have some controls, PaintBoxes, sized at 20x20 in 96 dpi. If I compile it in Windows 96 dpi, and then run it in 144 dpi, the PaintBoxes display as 20x20. If I recompile in Windows at 144, they rescale to 30x30. All high DPI settings on. ---------------------------------------------------------------------- VTwin · 2019-07-26 00:22 Quote from: wp on July 26, 2019, 01:32:41 amQuote from: VTwin on July 26, 2019, 01:18:19 amI note also that compiling on Win 7 at 144 requires a change, even a small one, to a form to get it to recompile and display correctly at 144. I don't think that this is essential: with the tiny change a new lfm is written on the 144dpi system and it contains the new dpi value. When this file is opened on the 144dpi system next time, no conversions have to be executed because the dpi values are matching. Without a change the lfm is not written to disk at all even if you changed code in the pas file, but this means that the lfm still contains the old dpi value. When the project is opened the next time on the 144 dpi system scaling should occur due to the different dpi values. I'm not clear on that. The control sizes were definitely not changing unless I made a small change in the form designer. I am speaking of designing the form on a Mac at 96, and trying to recompile on Windows at 144. It happened every time. ---------------------------------------------------------------------- VTwin · 2019-07-26 02:07 I honestly do not know what to do. Ignore DPI, release for multiple DPIs? I would appreciate guidance. ---------------------------------------------------------------------- kupferstecher · 2019-07-26 09:40 Quote from: wp on July 26, 2019, 01:06:27 amAlthough I don't understand why somebody might want to turn scaling off...I can think of a list of reasons. - Backward compatibility - Usage of components that don't support scaling - Custom components that rely on predefined dimensions - Project stage, where scaling is not tested on different values yet, i.e. to guarantee a working application on different OS settings. Because of the first and last point in my opinion the scaling should be off by default. I'd compare the scaling to i18n. It's an additional feature of the application that needs to be cared about on development. You couldn't say it always works out of the box. -- I just tried to make a demo application and I'm even more confused now. When scaling settings are off, the application will still scale, both on design time and run time. But I have an existing application (some years old), that behaves differently. On designtime it will scale, but once compiled it will keep its original settings on any scaling factor of the OS*. The Project settings are the same ("scaled value" and "dpi aware" in the lpi-files both are disabled). I can't find what is different...*2 *Edit: Some controls are scaled as well, e.g. check boxes, combo boxes. *2:Just checked again. If I enable scaling (Laz 2.0.2) for the "old" program, compile and disable it afterwards again, it always scales, so it changes behaviour. If I open it with Laz 1.8.0 again, the original behaviour, scaling only at design time works again, also if compiled with Laz 2.0.2. There's obviously a bug. Should I also check with current trunk? What is the intended behaviour? ---------------------------------------------------------------------- wp · 2019-07-26 15:12 Quote from: kupferstecher on July 26, 2019, 12:09:39 amQuote from: wp on July 25, 2019, 04:29:47 pmOf course, with scaling to a higher resolution, say 150% all dimensions must increase by this factor. This is way scaling is done after all. Suppose you have a 26" monitor with, say 2000x1000 pixels (numbers selected for simplicity of calculation). Then you go to a "Super real-life retina display", same size but with 3000x1500 pixels (i.e. 150% more in each dimension. Without scaling a form of 2000x1000 pixels would fill the entire screen on the 2000x1000 monitor, but only part of it on the 3000x1500 model. If scaling is activated, then yes. But seems Lazarus also scales the design time form if scaling is disabled in the settings (using Laz 2.0.2). I.e. if I design a form under Win 7 125% with disabled scaling and I change dpi-settings of Windows to 100% then the form will be much smaller. On the same time a form designed and compiled under a dpi-settings will stay in the original size no matter under which dpi- setting the Exe is run. The paradigm 'Write once, compile everywhere' is broken for disabled dpi scaling (and backward compatibility as well). Can someone comment on that? I may be wrong as I'm not familiar with dpi-scaling yet. I played with deactivated LCLscaling myself and must say that your observations are correct. Very confusing. I contacted Ondrej Pokorny who wrote these routines for the LCL. ---------------------------------------------------------------------- kupferstecher · 2019-07-26 15:46 Hello wp, thanks for testing. I played around, again. On Lazarus 1.8.0 with disabled scaling it worked as I would expect it. No scaling in the design time and no scaling on runtime. ---------------------------------------------------------------------- wp · 2019-07-26 17:02 Are Laz 1.8.2 and 1.8.4 behaving like 1.8.0? Can you try to find out which revision in trunk broke it? ---------------------------------------------------------------------- kupferstecher · 2019-07-26 17:12 Then I have to install them. With fpcupdeluxe that takes several hours. I'm afraid I couldn't find the relevant revision (But for the release I can try). ---------------------------------------------------------------------- wp · 2019-07-26 17:41 No problem. I can try myself. [EDIT] The change is introduced by r56975, "IDE: new designer option: Force DPI scaling in design-time". This introduces the "Force DPI scaling in design-time" checkbox. Therefore, I guess that in order to avoid changing of scaling by the IDE when a project is moved to another computer at different dpi this checkbox should be turned off, as already has been suggested somewhere (I myself have never changed this option...) ---------------------------------------------------------------------- VTwin · 2019-07-26 18:46 I wanted to note that I have now had considerable success compiling on Win 7 at 96 dpi, and then running the executable on Win 7 144 dpi without recompiling. I was having trouble with PaintBoxes that were not resizing correctly. The PaintBoxes are used as a control to select colors, symbols, etc. As wp pointed out, the PaintBox in my demo worked fine. I had been initializing them in FormCreate, and after the discussion here, I realized that they needed to be initialized in FormShow. I am now optimistic that my software can run well on different DPI machines. The last chore will be to modify bitmaps I use for toolbars and menus, which were created to work at 96 dpi. Thanks! ---------------------------------------------------------------------- wp · 2019-07-26 19:54 Quote from: VTwin on July 26, 2019, 08:46:16 pmThe last chore will be to modify bitmaps I use for toolbars and menus, which were created to work at 96 dpi. The new imagelist of Laz 1.8+ supports images at several resolutions. When you set ImageList.Scaled to true the size needed for the current PixelsPerInch is selected or interpolated. I once wrote the following instructions for using the dpi-aware imagelist: Activate the settings for a high-dpi project (LCLScaling on, dpi-aware manifest)Set ImageList.Scaled to trueThe image size set up by Width and Height are taken as initial size for 96 ppi. Starting with large images (64x64, or 32x32) means that missing smaller images will be down-scaled which has good quality. Starting with small images (16x16) will create missing images by upscaling which results in poorer quality. Usually it is sufficient to provide only the largest images.In the imagelist editor do this:Click "New resolution" and enter the resolutions for which additional images are needed. Image sizes usually needed are 16x16, 24x24 abd 32x32 on 96ppi, 144ppi and 192ppi monitors for Listview's smallImages and menu and usually toolbar. In case of Listview's LargeImages, additionally 48x48 and 64x64 are needed. Only the width needs to be entered Add new images by clicking "Add" or "Add more resolutions" -- it will load the image(s) and calculate the missing sizes. The difference is in the effect when several images are selected in the file dialog: "Add" creates separate items for each selected image at all resolutions. "Add more resolutions" adds a single image and assumes that the selected images show the same picture but at different resolutions.If the same image is available at other resolutions click "Replace all resolutions" for each size - this will replace the calculated image by the "real" one. As already noted not necessarily needed."Replace" replaces only the reference size image (the size specified in the Width and Height of the imagelist)."Delete" removes the versions of the selected image, "Clear" removes all images if you want to start all over. Note that this will erase the added resolutions as well. ---------------------------------------------------------------------- VTwin · 2019-07-26 20:12 Excellent! That will greatly assist with the task. ---------------------------------------------------------------------- VTwin · 2019-07-30 15:10 The imagelist editor is working very well for me. Although the automatic rescaling works well, I prefer the option to include multiple resolutions, so have been doing that. Question 1. Does Lazarus always scale an icon down from the next higher resolution? That is, if I had 32 and 48 pixel icons, and needed 36, it would scale from 48->36, and not 32->36. Question 2. On Windows, it looks as if dpi scaling options (in some cases) include 100%, 125%, 150%, 175%, and 200%. If I include only, for example, 16 (for 100%), 24, and 32 pixel icons, what happens at the 125% and 175% dpi options? ---------------------------------------------------------------------- wp · 2019-07-30 16:29 Quote from: VTwin on July 30, 2019, 05:10:30 pmThe imagelist editor is working very well for me. Although the automatic rescaling works well, I prefer the option to include multiple resolutions, so have been doing that. Question 1. Does Lazarus always scale an icon down from the next higher resolution? That is, if I had 32 and 48 pixel icons, and needed 36, it would scale from 48->36, and not 32->36. The source code tells that it takes the next higher resolution: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function TCustomImageListResolutions.FindBestToCopyFrom(const ATargetWidth,  AIgnoreIndex: Integer): Integer;begin  for Result := 0 to Count-1 do // find the smallest (but bigger) image    if (Result<>AIgnoreIndex) and (Items[Result].Width>=ATargetWidth) then      Exit;   Result := Count-1; // just pickup the biggest image to scale up  if Result=AIgnoreIndex then    Dec(Result);end; Quote from: VTwin on July 30, 2019, 05:10:30 pmQuestion 2. On Windows, it looks as if dpi scaling options (in some cases) include 100%, 125%, 150%, 175%, and 200%. If I include only, for example, 16 (for 100%), 24, and 32 pixel icons, what happens at the 125% and 175% dpi options? The IDE only seems to take care of 100%, 150%, 200% automatically. The mapping rule is in TCustomImageList.GetWidthForPPI: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function TCustomImageList.GetWidthForPPI(AImageWidth,  APPI: Integer): Integer;var  Factor: Integer;  idx: Integer;begin  if AImageWidth<=0 then    AImageWidth := FWidth;   if not FScaled then    Result := AImageWidth  else begin    Result := round(AImageWidth * APPI / 96);  if not FData.Find(Result, idx) then begin      if APPI <= 120 then      Factor := 100 // 100-125% (96-120 DPI): no scaling      else      if APPI <= 168 then        Factor := 150 // 126%-175% (144-168 DPI): 150% scaling      else        Factor := Round(APPI/96) * 100; // 200, 300, 400, ...      Result := AImageWidth * Factor div 100;    end;  end;   if Assigned(FOnGetWidthForPPI) then    FOnGetWidthForPPI(Self, AImageWidth, APPI, Result);end; This means that 120ppi (125%) are handled as unscaled, and 168ppi (175%) as 150%. The last line, however, shows that you can implement your own rule in the TCustomImageList.OnGetWidthForPPI event, e.g: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm1.ImageList1GetWidthForPPI(Sender: TCustomImageList;  AImageWidth, APPI: Integer; var AResultWidth: Integer);begin  if (APPI >=115) and (APPI <= 125) then AResultWidth := 24;end; It is not necessary to provide images for these intermediate resolutions. Of course, for ultimate quality, correctly scaled images are preferable. ---------------------------------------------------------------------- VTwin · 2019-07-30 18:23 Thank you wp. I should have poked around more in the code myself. I appreciate your detailed answer. That seems like a good way to handle the sizing, and is good news. I was concerned about having to prepare for all dpis that Microsoft (or others) might throw at me. I will stick with 100%, 150%, and 200%, and know that Lazarus will pick the best one.