MTEXT editor Slow.....

We like Bricscad but are finding that it is very slow to open the MTEXT editor.  We are using the latest release.  Is there a resolution to this?

Comments

  • Could you please file a support request and attach a sample drawing, along with a description how to reproduce the problem? We will be glad to investigate what causes the slowness.

    Kind regards,

    Hans De Backer

  • I had noticed it in the past and again just recently, but it's not slow in all drawings and at all times.

    Doesn't even seem to be always slow in any one file.

    I have not got as far as identifying the circumstances it slows down in, the behaviour seems to go away as quickly as it appears and doesn't stay for long.

    If I try using Notepad when it happens, that's fairly slow too.

  • I frequently have a 3 to 4 second lag between double clicking the mtext to the mtext editor appearing.  Just haven't had a chance to find out what causes it.  Will look into it when I have some down time if someone else hasnt discovered the cause beforehand.

  • I am also experiencing a very slow Mtext operation (3-4 secs to open). On one laptop (2Ghz, 2Mb RAM) it happens whenever I use Mtext (even on an empty file). I loaded BriccadV10 on a Asus (1.6 Ghz, 1 Mb RAM) Netbook and Mtext works fine.

    Using Notepad works OK, except that I do not have any formatting options and I cannot insert / edit in-place.

  • Not sure if it is too early to say; but I think my lag seems to have disappeared with the latest Beta. I don't know if it was something that was updated or if it was just the new install.

  • My latest incarnation of the slow gremlin seems to have both arrived and departed all within 10.2.13

    About all I can state is that prayer had no part in it.

  • In 10.3.9 beta:

    "SR23473 - MTEXT: when many shx fonts exist in the font search path, there was a noticeable delay before the Mtext dialog opened. This delay is avoided now by caching shx font data."

  • Is that the program's search path or the particular file's, Damian?

    I have quite a few extra fonts and speed is mostly fine.

    Have not noticed that files with many fonts have the problem, although they are often the files with too much fluff and are slow generally before I clean them out, purge etc.

    Files with a lot of text formatting characters (like "{\blahblah;") are often slow, not just in the mtext editor.

    I use 2 lisps to strip the extra characters from text and mtext.

  • Thanks Damian. I look forward to the next release.

    However, I removed all but a dozen shx fonts and found that while the speed of opening text did speed up but it was still on the slow side.

    Could I try the Beta you refered to?

    Thanks

  • Walter, send a support request to the Bricsys team and ask to be a Beta tester.

  • Some background info for those that are interested: when the Mtext editor is about to open, also in an empty drawing, it fills its' font combobox with all TTF and SHX fonts that can be found on the computer. For the TTF font data the operating system is queried, for the SHX fonts we search the Support File Search Path (this is the list of paths stored in system variable SRCHPATH). All files with extension .SHX are opened and verified if they contain a valid SHX font, if so, it is added to the list. The more SHX files, the longer this takes. Even the sheer number of files that exist in the SRCHPATH paths will influence the time it takes to find SHX files. The speed with which the operating system can look up files, will also depend on folders being indexed for fast searching or not. Disk fragmentation will make a difference, etcetera...

    Hope this sheds some light and clarifies why on some system Mtext editor will suffer opening delay, and run fine on another one, or how on the same system, one Bricscad version will have a different Mtext dialog open speed from another one if their SRCHPATH is different...

    Thus, to avoid this repeated opening delay, we now cache the SHX data the first time it is read.

    Kind regards

This discussion has been closed.