-
Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.
If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.
- The Lone Wolf Development Team
Font Memory Issue
- Thread starter Parody
- Start date
craghammer
Active member
My bad - I didn't see the large padlock on the post indicating that is is private (who knew you had yo pay to do that...)
My initial question to the devs was:
This is a Windows Application that uses a lot of memory when running, due to the application loading all system fonts available and this results in sluggish response and occational crashes.
Is there any way to limit the number of fonts loaded into the application (When using the Font dropdown list for a text editor) - limited to a number of reasonable useful fonts?
The goal is to load less fonts (preferably a predefined list) with some fallback to other font-families.
And the reply is (from Aleks):
Unless I am mistaken, your task is to limit the number of available fonts in FontEdit. For this, you can use the approach described in the Customizing Font list on Font Bar ticket. In short, you can clear the collection of available fonts and populate it with required fonts as shown in the code snippet below:
[C#]
repositoryItemFontEdit1.Items.Clear();
repositoryItemFontEdit1.Items.Add("Calibri");
repositoryItemFontEdit1.Items.Add("Arial");
He refers to this (public) ticket also.
I've asked a followup question regarding if this is a global setting or not, it seems a bit of a hassle to do this for every instance of FontEdit. One approach could be a helper class on the FontEdit control that resets the Item Collection, or creating a new "RWFontEdit" class that inherits FontEdit and sets the properties, and then use the new class for all instances of FontEdit (go ReSharper!)
My initial question to the devs was:
This is a Windows Application that uses a lot of memory when running, due to the application loading all system fonts available and this results in sluggish response and occational crashes.
Is there any way to limit the number of fonts loaded into the application (When using the Font dropdown list for a text editor) - limited to a number of reasonable useful fonts?
The goal is to load less fonts (preferably a predefined list) with some fallback to other font-families.
And the reply is (from Aleks):
Unless I am mistaken, your task is to limit the number of available fonts in FontEdit. For this, you can use the approach described in the Customizing Font list on Font Bar ticket. In short, you can clear the collection of available fonts and populate it with required fonts as shown in the code snippet below:
[C#]
repositoryItemFontEdit1.Items.Clear();
repositoryItemFontEdit1.Items.Add("Calibri");
repositoryItemFontEdit1.Items.Add("Arial");
He refers to this (public) ticket also.
I've asked a followup question regarding if this is a global setting or not, it seems a bit of a hassle to do this for every instance of FontEdit. One approach could be a helper class on the FontEdit control that resets the Item Collection, or creating a new "RWFontEdit" class that inherits FontEdit and sets the properties, and then use the new class for all instances of FontEdit (go ReSharper!)
Last edited:
craghammer
Active member
New info from the DevExpress support team - more clues to follow up...
First, I would like to note that the increase in memory usage when fonts are loaded happens because all existing font files are memory mapped and kept in memory while the corresponding process exists. This behavior is reproducible with the .NET FontFamily class without using our components. Once the FontFamily.Families property is accessed, the font files are mapped to memory. Even if the FontFamily.Families collection is disposed of, the memory-mapped files stay in memory. The operation system manages the removal of these files. So, if you delete items from the RepositoryItemFontEdit.Items collection, the free memory is not increased.
First, I would like to note that the increase in memory usage when fonts are loaded happens because all existing font files are memory mapped and kept in memory while the corresponding process exists. This behavior is reproducible with the .NET FontFamily class without using our components. Once the FontFamily.Families property is accessed, the font files are mapped to memory. Even if the FontFamily.Families collection is disposed of, the memory-mapped files stay in memory. The operation system manages the removal of these files. So, if you delete items from the RepositoryItemFontEdit.Items collection, the free memory is not increased.
That's a dagger to the heart on this idea.
If they all get mapped into the memory space, and never released, there's nothing we can do at the application level.Sad panda.
That's what I was worrying about, and what folks were describing in other places (with occasional "only on Windows 10" theories).
The workaround they had is getting font info from the system directly, bypassing .NET/GDI+ except for fonts you actually use. Not really an option here.
To me this still seems like a bug or poorly chosen feature; fonts should get flushed from memory like everything else. Microsoft's made a bunch of these types of decisions lately. :(
On to 64-bit, I suppose.
The workaround they had is getting font info from the system directly, bypassing .NET/GDI+ except for fonts you actually use. Not really an option here.
To me this still seems like a bug or poorly chosen feature; fonts should get flushed from memory like everything else. Microsoft's made a bunch of these types of decisions lately. :(
On to 64-bit, I suppose.
I'm about as big a MS partisan as they come. I've been a Windows programmer my whole career but .Net was badly done from top to bottom. I have run into a bunch of things that were show stoppers for programs that rose above the level of class project or demo. Not that Java works a lot better tbh.
I'm truly amazed RW works as well as it does. I'm just glad the option to move to 64 bit does theoretically exist.
I'm truly amazed RW works as well as it does. I'm just glad the option to move to 64 bit does theoretically exist.
There's nothing that can be done unless they move away from the DevExpress controls and (in general) .NET's font handling, which is exceedingly unlikely.
A 64-bit version of Realm Works would reduce the impact; all the fonts would still get loaded and use memory, but the memory limit would be removed. The fonts you don't use would likely get loaded but eventually paged out and you wouldn't care anymore.
Otherwise, look into font managers or wait for a web version.
Last edited:
When Windows XP was the dominant desktop operating system. Not much choice there.
32-bit Windows can still be found on new (but low-end) Windows laptops/tablets/convertibles. The processors support 64-bit, but they install 32-bit Windows because the devices only have 1-2 GB of RAM and very few applications are 64-bit only.
There's also the existing install base; the last numbers I had seen said that roughly half of Windows 7 installs were 32-bit, and if they updated to Windows 10 they'd get Windows 10 32-bit.
My own convertible fits both of the above; it came with Windows 8(.0) 32-bit and now has Windows 10 32-bit. It runs Realm Works well enough for my purposes.
Offering both seems a likely path, assuming their dependencies offer both and they want to accept the development and testing burden of two versions. I doubt they want to put off the Content Market for it, though.
Last edited:
This is my hope as well.