LarsenCommander - new test version

[Rich Walsh]

I would like to have something that saves me some time grabbing by default font size (as XWP shows as default), but I understand that it is not easy to implement for each component described in the Font settings of lcmd.

It shouldn't be particularly hard: there are 5 entries under 'os2.ini->PM_SystemFonts'  [see below] and you map them to your categories. For example, 'PM_SystemFonts->Menus' maps to lcmd's 'AppWin.MenuBar' and its other menu settings.

DefaultFont: System Proportional - if this entry is missing/empty, assume 10 point SysPro

IconText:  WarpSans - this is mislabelled, it should be "Folder text" since it also is used for Details view
WindowText: WarpSans - standard dialog text

Menus: WarpSans Bold - both menubars and popups
WindowTitles:  WarpSans Bold

The key to using defaults while still allowing customization is *never* save the default value. That way you don't get stuck with a value that _used_ to be the default but isn't any longer.

[Rich Walsh]

there are 5 entries [...] and you map them to your categories.

FWIW... you're not limited to just the 3 default fonts. Rather, you can use these entries as guidelines for setting the correct size of your preferred typeface. For example, if lcmd uses 'Helv' somewhere, you can get the entry for the category (say, "menu") but only pay attention to the size (use 'atol(...)). If 'Helv' has that point size, use it. Otherwise, go up or down at point _or_ substitute WarpSans (non-bold).

Do all this during init and save the results so you don't have to duplicate a lot of code. (Note: the default values in 'os2.ini' will never change during a session - they're only updated during shutdown - so there's no need to check for  new values.)

[Andi B.]

I understand the problem for people with high resolution screen usually found in modern Notebooks. But I think it should be possible with current version to set all controls to the needed bigger fonts. This setting should survive restarts. I'm I right Martin?

If yes I think it's not high priority to invest much time in this and so there's nothing which I can do in near future. F.i. the (rare) crashes and some leak in currently unknown system resources are more important IMO.

I just wait on Martins response and if there is no real show stopper (f.i. some controls can't be changed to usable fonts) I'll create a ticket with all the valuable infos from Rich. Maybe some time someone finds the time to make a more elegant solution for that.

[Martin Iturbide]

Hi Andi B.

I understand the problem for people with high resolution screen usually found in modern Notebooks. But I think it should be possible with current version to set all controls to the needed bigger fonts. This setting should survive restarts. I'm I right Martin?

If yes I think it's not high priority to invest much time in this and so there's nothing which I can do in near future. F.i. the (rare) crashes and some leak in currently unknown system resources are more important IMO.

I just wait on Martins response and if there is no real show stopper (f.i. some controls can't be changed to usable fonts) I'll create a ticket with all the valuable infos from Rich. Maybe some time someone finds the time to make a more elegant solution for that.

Like you said, this is not high priority. For me it is a "nice to have", it is not a bug. If there are no resources to do this, I think it is fine just to document it with a ticket.

Regards

[Dariusz Piatkowski]

Hi Andi,
...
File xfer performance wise, here are the results for movement of a test 800M AVI file:

1) from SAMBA share to ramdisk
OLD:  Peak=58,270K, Avg=43,550K
NEW: Peak=56,220K, Avg=46,516K

...so I'm thinking this is more about being network bound (1G LAN, but of course the Samba share box - NAS is the limitation here)

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD:  Peak= 82,788K, Avg=  45,545K
NEW: Peak=310,118K, Avg=220,910K
...

Repeat of the same performance tests for the newest version:

1) from SAMBA share to ramdisk
OLD: Peak=56,220K, Avg=46,516K
NEW: Peak=51,367K, Avg=45,832K

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD: Peak=310,118K, Avg=220,910K
NEW: Peak=503,901K, Avg=311,825K

...which naturally made my eyeballs nearly pop out b/c let's be honest, my SSD isn't that fast!!!

So a re-do produced the following NEW:
NEW: Peak=430,674K, Avg=183,007K

...which while still pretty high for a Peak, I suspect this has everything to do with my crazy ass JFS cache, which is 1G in size.

Couple more tests later though the higher Peak appears to be sustained, so perhaps there is a little bit more improvement here Andi!!!?

Thank you again!

[Andi B.]

Speed tests with SSDs vary on my system. I've tested with -
Samsung SSD 850 PRO 256GB
Samsung SSD 870 EVO 2TB
Samsung SSD 860 QVO 1TB
Crucial CT500MX500SSD1

It's sometimes not clear why copying from one SSD to another is faster with some setting while it's a bit slower with another target or source. I ever thought the maximum throughput you can get with an OS/2 system is copy from CLI cause a GUI program with progress indicator will always lower performance (the progress indicator needs to be update while CLI copy only waits for disk to accept new data, CLI does not even check CTRL-C). To my findings this is still true with disks although now LCMD comes very close to CLI. But in the last months I've even found scenarios where copying with LCMD is much faster than CLI copy (which TTBOMK uses 4k fixed buffer).

You may think copying with LCMD should be faster when not much else is running at the same time. But I've even scenarios where copying is actually a bit faster when LCMD lost the focus and some other heavy task are running. Once I even need a reboot to get the copy speed from/to a specific source/target to the level I'm used to. It was about 20% slower for unknown reason before.

Bottom line is it needs a lot of tests to get reproducible results. In most scenarios you can't get the same full speed with LCMD than with CLI but we are very close to that. Facts based on my tests for single big files are -
- Samba is way slower than ftp (more than 1,5 times slower here), both via netdrive *)
- for SSDs and harddisks LCMD is not exactly as fast als CLI copy but very close to it
- Ramdisk is way slower than SSD or harddisks (JFS is faster than HPFS but still 3 times slower)
- Peak values may be very high cause of SSD (and JFS) cache

*) Samba is way faster than FTP with a lot of small files I think because of it's directory caching which FTP is missing