@roberto-arista Great, thank you for the heads up, and thank you @frederik for all the work on RF4!

In many cases I find a lag in RF interface. It feels RF is not responsive as before or is slow in way that is blocking me from doing a task. I forget to document or report them. So here is a start: BaseEventTool shift key release To reproduce the issue perform the following: Open a glyph which contains an anchor. Select the anchor using mouse and the basic editing tool. Drag the anchor in a fast reptitive motion. While dragging, hold the shift key and release it, but don't release the mouse while doing so. Now the anchor that was being dragged is lagging behind the cursor. Same thing happens with contour nodes. Is there any reason this is happening?

I've found some tips about making things run faster in RF and I want to share them here. I hope they're useful for others too: 1. Python objects are faster than RF font objects I realized if my script is run once, it's better if I convert RF objects to python objects. This way in many cases there is a huge performance boost. This could also be dangerous if you keep the data after user made changes to the font. So if you want to do something once and you're done after, this might help. Here is a very small public gist, but it's a start: https://gist.github.com/typoman/38a41811ad5dd8eb16a9d8acb6519a7f 2. Representation factories If you're making a user interface and are calculating something every time user makes a change, the representation factory is the way to cut some time. This is how you can cache data in font. Representaions can be anything, it doesn't have to be a visual data. RoboFont already has many. Like Glyph.area which gives you the surface area of the glyph. You can find how to make representation factories here: https://github.com/robotools/defcon/blob/master/documentation/source/concepts/representations.rst An example: https://github.com/typesupply/glyph-nanny/blob/2d41cc0e200726b2ddc5ffda3f85caeee7a7235b/Glyph Nanny.roboFontExt/lib/glyphNanny.py#L627

Thanks for the breakdown, @colinmford! I suspected that to be the case, but it's helpful to have it confirmed. Very good point on the SSD. I haven't had a spinning-disk hard drive for awhile, but yes, I could see that really degrading performance for UFOs. Hmm, interesting hack on running multiple instances of RoboFont! On certain file-processing workflows, I might try to take advantage of that...

hello @RafaŁ-Buchner, this is a great summary and a very valuable test case. please let us know how it goes! something I wish I knew when I was upgrading to RF3: you can use different folders for your RF3 and RF1 extensions. this allows you to start fresh in RF3 without messing up your current RF1 extensions setup. (the extensions folder can be configured in Preferences > Extensions) another place to keep an eye for error messages and tracebacks is the log file. (use the keyboard shortcut ⌃ ⌘ ⌥ O to jump to it in Finder) setting warningsLevel to always is good for detecting problems, but I would recommend setting it to ignore while working. (printing a lot of deprecation warnings to the Output Window might slow things down a bit) ps. most extensions have been upgraded to RF3 by now, so switching to RF3 today is smoother than it was 1 year ago. (those who tried and gave up are encouraged to try again :)

very strange indeed... I cannot reproduce this on 10.13, will try on a 10.14 later on today.

@d7yrr ok. as I suspected :) there’s an issue with the latest build in macOS Mojave; @frederik is looking into it. a warning for Mojave users has been added to the Downloads page. please try using one of the previous builds – that should fix the performance problems you are experiencing. thanks for reporting it. let us know if you still have any problems.

TL;DR a long text string in MM preview window slows it to a crawl. Can it be faster? When I kern a pair of letters, I have a string of words in the preview window to check them in context. For example, if I’m kerning an Upper/Upper list and I’m on J/UC, I'll paste this string into the window: J JARN ENAJER HEBJORN HOCJERM HODJERN REJOINER FJERNISCHE LAKJERNIS REJOINER KLIPJENNI MARJORAM SJORNE MATJINKO JUNIPER HUJIME HIVJINE HIJVINE HIJWINE HIWJINE HIJYINE HIYJINE HIZJINE HIJZINE A string this long really slows the extension to a crawl. The old standalone MM app used to handle a string like this. Is there any way to beef up the extension somehow? I’d really appreciate it!

good you found it! "printing" a traceback is very costly, but handy so you know what went wrong

That will not change much. But in the next version you will be able to open a glyph window for a font that has no UI. from mojo.UI import OpenGlyphWindow, OpenSpaceCenter path = u"path/to/a/font.ufo" f = OpenFont(path, showUI=False) # opens glyphs "a" in a glyph window OpenGlyphWindow(f["a"]) OpenSpaceCenter(f)

ufo2fdk is embedded and by default using the embedded FDK, you can disable the use of of the internal FDK in the preferences. The file menu option "Generate" or through scripting font.generate(...) is using FDK to build the binaries. It's up to you if you want to use the embedded FDK or a custom installed version on your local HD.