Font Memory Issue

[Parody]

So a question: is the memory usage dependent on the number of fonts installed or the number Realm Works can use?

I ask because I got the warning, but the majority of my fonts are Type 1 or OTF with Type 1 outlines, which Realm Works can't use anyway.

(Yes, I already checked "Don't show this again". :)

[Viking2054]

What about those of us that do some desktop publishing and sometimes use a lot of fonts?

Any chance we can get Realm Works to limit the number of fonts it loads? A handful each of serif and san serif fonts should be more then enough. Just allow the user to select the ones they want Realm Works to load...

[rob]

So a question: is the memory usage dependent on the number of fonts installed or the number Realm Works can use?

I believe it's based on the number of fonts that can be used. More below...

[rob]

What about those of us that do some desktop publishing and sometimes use a lot of fonts?

Any chance we can get Realm Works to limit the number of fonts it loads? A handful each of serif and san serif fonts should be more then enough. Just allow the user to select the ones they want Realm Works to load...

The Realm Works desktop client is built on a third-party framework (DevExpress). This framework simply loads all the fonts on the user's computer, so we don't have easy control over which fonts are or aren't loaded. We only discovered the font issue a few days ago, so we have only done a cursory investigation into our options at this point, but there was no readily apparent way for us to restrict which fonts are used. If anyone out there knows of a solution for this, we'd be happy to hear about it!

If you use lots of fonts for other purposes, then you'll absolutely want to keep them all. Some users will find that there are numerous fonts they never intentionally installed and have no use for, in which case they can be readily removed. Every user's situation will be different, and it's simply a trade-off between having the fonts versus having more/larger smart images actively loaded concurrently. Each user must make their own assessment, and it's important that users are made aware of this trade-off. That's why we present the warning, if necessary, and leave it to the user to determine how best to proceed. :)

[Parody]

I don't know DevExpress, but one thing you could try (if it lets you) is disabling font previews in the font selection combo boxes. The hope is that they then delay loading each font until it's actually used and just rely on the list of names provided by the system for selecting fonts. If most of us are using the defaults then Realm Works would only need the Tahoma variants, cutting potentially hundreds of loaded fonts down to four.

Edit: Actually two; Tahoma doesn't come with italics.

[BoomerET]

There are tools you can use that might help.

http://www.trishtech.com/font-loader/

This will take some work on the users part to work effectively.
(ie, uninstalling current fonts, saving them in a folder someplace, run the program when creating documents/DTP/etc)


Boomer

[Avi]

How many Fonts is "too much" or is it by "volume"?

[Topdecker]

Maybe a better approach would be to check in task manager and see how much memory is being used by Realm Works. I got the warning, but the actual consumed memory was 131mb or so, which did not seem especially large. I suspect that the message is generated by count of fonts, not by use of resources.

Top

[Joe]

Maybe a better approach would be to check in task manager and see how much memory is being used by Realm Works. I got the warning, but the actual consumed memory was 131mb or so, which did not seem especially large. I suspect that the message is generated by count of fonts, not by use of resources.

Top

Unfortunately its a bit more complicated than that. Task Manager doesn't show the complete picture of resource utilization. You can get a more complete view of things using a tool called "ProcessExplorer" if you're interested. On my system, Realm Works shows as using 133 MB in task manager, but Process Explorer reports the total virtual memory size as 1.3 GB.

Realm Works is a 32 bit application, so it cannot go above 2 GB of virtual memory. That is the ceiling being hit when the out of memory errors occur. We trigger the warning based on the virtual memory size, which is more directly related to the error occurring. It is not based on a simple count of the number of fonts. I think we trigger it above 1.2 GB, but I could be wrong on the exact number.

Hopefully I have not totally misled on any of the technical details. If so, Rob or David will need to correct me.

[rob]

Joe summed things up nicely.

To specifically answer the question from @Avi, Realm Works looks at the total memory utilization, wherein all the fonts can make a huge difference from one user to the next. Some fonts are much larger than others, so that's also a point of consideration. And the actual memory used by a particular font once loaded for use is typically larger than the size of that font on disk. However, the relative sizes of the fonts on disk seem to generally map to their memory footprint (i.e. larger fonts on disk use more memory once loaded).

Hope this helps! :)

[Parody]

Expanding on the info provided in the 217 release notes:

If you're looking to remove fonts from your system, think about which programs you've installed that might have also installed fonts, like office and design programs. Try using their installers or their entry in the Programs and Features Control Panel to selectively remove unwanted fonts rather than just deleting them from the Fonts folder. That way the programs "know" they're gone and you shouldn't run into problems like the one described.

However, if you've been adding fonts yourself and/or you don't know which fonts came from where, switch the Fonts folder into Details view and sort by "Designer/foundry". Any fonts whose foundry is "Microsoft Corporation" should be left alone. (On my Windows 10 install I believe a couple of these came with Office, but most are system fonts and shouldn't be removed.)

Note that this isn't comprehensive; some of the most commonly used fonts that come with the system are from other foundries. Arial, Courier New, and Times New Roman, for example, are from Monotype. It does, however, give you a visible baseline for which fonts you shouldn't be stubborn about removing!

Microsoft does provide lists of fonts that come with various products (https://www.microsoft.com/typography/fonts/product.aspx), but unfortunately these haven't been updated for more recent releases like Windows 10 or later versions of Office. Wikipedia has a list of typefaces included with Windows (https://en.wikipedia.org/wiki/List_of_typefaces_included_with_Microsoft_Windows) that does include Windows 10, but I haven't checked it personally.

[kbs666]

I'm still sort of impressed by the user who found a way to delete Tahoma. Windows doesn't like it when you try and mess with the system fonts.

Still not as bad as the Eve installer deleting C:\boot.ini a few years back.

[Parody]

Booting off a boot disc/drive would work; the recovery console would probably work. I don't really want to find out, though. :)

[kbs666]

I was lucky in that I had a recovery disc available, IIRC this was 2007. But a lot of people had to do full reinstalls of Windows. It goes to show that you should never name something the same as a vital system file even if it will be in a separate directory.

[craghammer]

Imho, removing Fonts from the system is not a very viable option. I have two reasons this is not good (at least for me); 1: Windows won't let me (may be policy rules), 2: I need a lot of fonts for my professional and private work.
One option would be to load only the necessary fonts into the RW runtime, but by using 3rd party librarys like DevExpress you might not be able to control that, but that sounds weird to me as a .NET developer.
Have you explored the various UI improvements that DevExpress offers? The UI could (in the far future when you have time) benefit from some upgrades to a more modern UI :)

Is there any work on moving RW to 64-bit?

[Parody]

It's a workaround. Not one I plan on using either, since I need the fonts I have installed for various projects, but for some folks it may be an option. It is unusual that you would be prevented from changing fonts, but if it's not your machine then you may well have policies set.

Poking around the Internet brings up a couple of posts pointing towards .NET applications (which use GDI+) on Windows 10 using a lot more memory when working with fonts than on Windows 7. No idea if it's true, though (FWIW) I am on Windows 10 now.

[rob]

Imho, removing Fonts from the system is not a very viable option. I have two reasons this is not good (at least for me); 1: Windows won't let me (may be policy rules), 2: I need a lot of fonts for my professional and private work.
One option would be to load only the necessary fonts into the RW runtime, but by using 3rd party librarys like DevExpress you might not be able to control that, but that sounds weird to me as a .NET developer.
Have you explored the various UI improvements that DevExpress offers? The UI could (in the far future when you have time) benefit from some upgrades to a more modern UI :)

Is there any work on moving RW to 64-bit?

It's NOT presented as something that users SHOULD do. It's merely presented as an option. We're informing users of what's going on with their system and the implications it has on their experience using Realm Works. It's entirely up to the user regarding what they choose, and some users won't be able to do anything about it, even if they want to. But lots of casual computer users will be completely unaware of all the silly fonts that are cluttering up their system, and they may appreciate being able to reclaim a lot of that essentially wasted memory. :)

As I indicated up-thread, we haven't done a thorough investigation regarding the font loading within DevExpress, but there is no readily apparent solution we've found. I'm pretty sure it would be possible, but then it's a question of how much work is involved and whether we should be spending our time on that instead of the many other features users are clamoring for. If you know of a quick solution with DevExpress, please let us know.

Your suggestion of revamping the UI to take advantage of recent improvements to DevExpress has one major drawback. Reworking the UI will entail LOTS of work that will result in no forward progress on new capabilities while that is going on. Given how loudly many users have been clamoring for a laundry list of new features, that would probably go over poorly with a lot of users. It's a damned-if-we-do, damned-if-we-don't situation.

Migrating RW to 64-bit is something we've looked into, but we haven't actively pursued it yet. It will entail a fair bit of work to accomplish due to a few key factors. Ultimately, a 64-bit solution looks to be the best solution overall. However, we've been focused on getting the Content Market into place, so work on stuff like that has not yet been undertaken.

[craghammer]

It's NOT presented as something that users SHOULD do. It's merely presented as an option. We're informing users of what's going on with their system and the implications it has on their experience using Realm Works. It's entirely up to the user regarding what they choose, and some users won't be able to do anything about it, even if they want to. But lots of casual computer users will be completely unaware of all the silly fonts that are cluttering up their system, and they may appreciate being able to reclaim a lot of that essentially wasted memory. :)

As I indicated up-thread, we haven't done a thorough investigation regarding the font loading within DevExpress, but there is no readily apparent solution we've found. I'm pretty sure it would be possible, but then it's a question of how much work is involved and whether we should be spending our time on that instead of the many other features users are clamoring for. If you know of a quick solution with DevExpress, please let us know.

Your suggestion of revamping the UI to take advantage of recent improvements to DevExpress has one major drawback. Reworking the UI will entail LOTS of work that will result in no forward progress on new capabilities while that is going on. Given how loudly many users have been clamoring for a laundry list of new features, that would probably go over poorly with a lot of users. It's a damned-if-we-do, damned-if-we-don't situation.

Migrating RW to 64-bit is something we've looked into, but we haven't actively pursued it yet. It will entail a fair bit of work to accomplish due to a few key factors. Ultimately, a 64-bit solution looks to be the best solution overall. However, we've been focused on getting the Content Market into place, so work on stuff like that has not yet been undertaken.

Thanks for the quick answer @rob, your responses are pretty on spot :) I'll look a bit into the font-loading issue and see if I can dig something up. Luckily I have 150 .NET devs around me, maybe someone has any insight (although, no guarantee ;) )

[craghammer]

@rob: This ticket might be an approach to limiting fonts in RW

https://www.devexpress.com/Support/Center/Question/Details/T452974

[Parody]

That ticket isn't public, FWIW:

You can't view this ticket

Log in if this is your ticket.

[rob]

@craghammer: Please re-post the substance of the DevExpress support ticket here or send it to us as part of your own support ticket with us. I'd very much like to know what the suggestion is. :)

[mazzy]

That ticket isn't public, FWIW:

We don't have the secret handshake :(

[craghammer]

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 (https://www.devexpress.com/Support/Center/Question/Details/T103975)(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!)

[rob]

Thanks for the help!

We'll take a look at this next week and determine if it's something we can leverage. <fingers crossed> The developer that most likely needs to investigate this is off for a few days this week (it's a holiday here in the States).

[Parody]

It may be too late at that point; you're Clear()ing a list that's been populated, which may have already loaded all the fonts.

(I wish I could play with this; programming by forum isn't that much fun. :)

And yeah, support tickets aren't always free.

[rob]

My hope is that, since it's .Net, the initial load would be incurred, but then all the discarded fonts would get GC'd when memory got tight, effectively giving back the RAM for something actually useful. <fingers crossed>

[kbs666]

That seems at least likely. The code snippet above seems to imply that the dev at DevExpress thought it was possible. You could force a sweep right after clearing the fonts and loading which ever ones you choose to load as well.

[AEIOU]

This is like watching an A-Team episode. Or MacGuyver. Virtual tape and bubble gum and hail Mary's.... Thank you, Craghammer and kbs666 and Parody and Joe and Rob!

[craghammer]

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.

[kbs666]

That may be unsolvable inside the app.

Eventually the solution may be to switch to 64 bit .Net. Not sure how many systems are still restricted to 32 bit architectures.

[rob]

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.

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. :(

[Parody]

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.

[kbs666]

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.

[Dhrakken]

Has there been any further developments on this issue or is this considered an unsolvable issue for the time being?

[Parody]

Has there been any further developments on this issue or is this considered an unsolvable issue for the time being?
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.

[Merion]

Realm Works is a 32 bit application, ...

Wait, what!?! Why? When did you start developing this?
http://images.google.de/imgres?imgurl=http%3A%2F%2Fvignette1.wikia.nocooki e.net%2Fthefakegees%2Fimages%2F0%2F0b%2FWait-What-Meme-11.jpg%2Frevision%2Flatest%3Fcb%3D20160707223315&imgrefurl=http%3A%2F%2Fweegeepedia.wikia.com%2Fwik i%2FFile%3AWait-What-Meme-11.jpg&h=412&w=600&tbnid=wl4qOld5DoWwmM%3A&vet=1&docid=igXbhtuLx1dMXM&ei=sYN3WPX-MJPtwAKal6ww&tbm=isch&client=firefox-b-ab&iact=rc&uact=3&dur=579&page=0&start=0&ndsp=45&ved=0ahUKEwi1m_-p2rzRAhWTNlAKHZoLCwYQMwggKAQwBA&bih=971&biw=1920


Migrating RW to 64-bit is something we've looked into, but we haven't actively pursued it yet. It will entail a fair bit of work to accomplish due to a few key factors. Ultimately, a 64-bit solution looks to be the best solution overall. However, we've been focused on getting the Content Market into place, so work on stuff like that has not yet been undertaken.

Phew! Alright, maybe this will also do away with the image size restriction? *hopeful*

[kbs666]

Is anyone still using 32 bit processors?

[Dhrakken]

Bueller? lol

[Parody]

Wait, what!?! Why? When did you start developing this?
When Windows XP was the dominant desktop operating system. Not much choice there.

Is anyone still using 32 bit processors?
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.

[Daelda]

Phew! Alright, maybe this will also do away with the image size restriction? *hopeful*

This is my hope as well.

[MaxSupernova]

> When Windows XP was the dominant desktop operating system. Not much choice there.

XP hasn't been the majority OS since mid-2009.

Has it really been nearly 8 years of development and we're still hoping that an upgrade that will set the stage for basic functionality might be released this weekend? Not the basic functionality itself, just the groundwork for it.

Whew.

[EDIT: Yep. The kickstarter, in Jan 2013, said they've been developing for over 3 years.]

[kbs666]

4 years since the kickstarter and 3 years prior to that in serious development seems about right for where the software is. People always seem to underestimate how long it takes to produce software.

[Parody]

To be honest, I thought XP was #1 until a bit later. It's easy to forget those tipping points unless you spend time on every post looking up the details. :(

Regardless of the exact timing, there were a lot of 32-bit only installs out there when they started.

[MaxSupernova]

"People" know how long software takes, and are well aware of timelines, slip, and obstacles involved.

7 years before basic goals are met is absurd.

"People" are still waiting patiently, but to defend this as normal is just Stockholm Syndrome.

[kbs666]

You don't. Just go back and look at the kickstarter video. Clearly the UI has gone through at least one full overhaul. Those always take a while, it probably involved changing or at least updating the UI library they used, which despite the beliefs of people who have never been involved in projects of this sort never goes as smoothly as the vendors claim it will. And that is just one thing amongst all of the many things that they surely have going on.