Lone Wolf Development Forums  

Go Back   Lone Wolf Development Forums > Realm Works Forums > Realm Works Discussion

Notices

Reply
 
Thread Tools Display Modes
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old November 21st, 2016, 11:57 AM
@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.
rob is offline   #21 Reply With Quote
mazzy
Member
 
Join Date: Mar 2016
Location: New Hampshire
Posts: 96

Old November 21st, 2016, 11:58 AM
Quote:
Originally Posted by Parody View Post
That ticket isn't public, FWIW:
We don't have the secret handshake
mazzy is offline   #22 Reply With Quote
craghammer
Member
 
Join Date: Dec 2015
Location: Oslo, Norway
Posts: 42

Old November 21st, 2016, 10:16 PM
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!)

Last edited by craghammer; November 21st, 2016 at 10:24 PM.
craghammer is offline   #23 Reply With Quote
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old November 21st, 2016, 11:57 PM
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).
rob is offline   #24 Reply With Quote
Parody
Senior Member
 
Join Date: Jan 2013
Location: Rochester, MN
Posts: 1,515

Old November 22nd, 2016, 01:22 AM
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.


Last edited by Parody; November 22nd, 2016 at 01:35 AM.
Parody is offline   #25 Reply With Quote
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old November 22nd, 2016, 01:41 AM
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>
rob is offline   #26 Reply With Quote
kbs666
Senior Member
 
Join Date: Oct 2014
Location: Chicago, IL
Posts: 1,690

Old November 22nd, 2016, 05:39 AM
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.

my Realm Works videos
https://www.youtube.com/channel/UCZU...4DwXXkvmBXQ9Yw
kbs666 is offline   #27 Reply With Quote
AEIOU
Senior Member
 
Join Date: Jan 2012
Posts: 1,147

Old November 22nd, 2016, 07:09 AM
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!
AEIOU is offline   #28 Reply With Quote
craghammer
Member
 
Join Date: Dec 2015
Location: Oslo, Norway
Posts: 42

Old November 22nd, 2016, 10:39 AM
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.
craghammer is offline   #29 Reply With Quote
kbs666
Senior Member
 
Join Date: Oct 2014
Location: Chicago, IL
Posts: 1,690

Old November 22nd, 2016, 10:49 AM
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.

my Realm Works videos
https://www.youtube.com/channel/UCZU...4DwXXkvmBXQ9Yw
kbs666 is offline   #30 Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 09:25 AM.


Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.