XMetaL Author Essent 12:the typing is lagging (slow) with increase of text size

[PaoloS]

Users reports that the typing experience is slow with increse of size of document.
With a relative big document (110kb of xml ) some times is very annoing use the editor.

As developer, i checked if there is some macro that running but i found correlations with the problem.

in Options > General > i tried to remove check from “Check spelling while typing” but not resolve the issue.

Binary#: 12.0.0.077
Installer#: 12.0.0238

Reply

[Derek Read]

This is true in general: the larger a document is the slower interactions with that document will be.

However, 110KB is nowhere near what I would consider to be “large”. I would say that's pretty small. We have clients that work with multi-MB sized documents. In some cases editing is “slow” but that depends on much more than simply XML file size. As an example, the sample “CamerasInFocus.xml” (that uses the fairly complex journalist.dtd) ships at 8KB. After copying and pasting content in that document to increase overall content size to 1.5MB I see no reduction in authoring interactions other than an increase in save time (which also does a full document validation by default), increasing from less than 1 second (at 8KB) to several seconds (at 1.5MB).

So, here are some things to look at:

The complexity of the document itself and the complexity of the schema (DTD or XSD) can contribute. In other words, a document consisting of one element containing thousands of lines of text will be easier on the software than a document with thousands of elements each containing a small amount of text. A document containing complex validation rules can also slow editing (complexity of the schema). In other words, if the software needs to decide between many elements, attributes, or values when inserting or changing or validating those things vs a simpler schema where there are only a few options editing the latter will be faster. These issues are primarily related to how XMetaL Author uses its “rules checking” feature to stop users from putting a document into an invalid state.

If none of the things below help then the primary strategy in this case would be to reduce document size (if the schema is not the issue or the schema cannot be altered) and then piece together multiple smaller documents when transforming the XML to its final output (if that is necessary).

Additional things that will slow editing include the complexity of the CSS used to render the document in Tags On and Normal view as well as macros that run when various actions take place. The CTM file can also have an effect, primarily if it contains script or if it is configured to render XFT forms with complicated scripting code or display many XFT documents inline in a document.

The “check spelling while typing” feature can also slow editing, so it makes sense to try turning that off, as you have done.

The “bidirectional text” feature (which is off by default) can drastically reduce editing speed, depending on which languages are being rendered, so if you don't need that feature make sure it is off.

You might try a test where you replace your CSS file and CTM file with empty files to see if that helps. If it does help then replace portions of those files until the issue returns to find out what is contributing to the slow down.

Macros that fire frequently (such as On_Update_UI) can slow down document editing, as well as macros that run less frequently but contain complex code, or macros that are relying on some external service to respond (these would typically be found with CMS integrations or systems that help with language such as spelling, grammar, controlled language database, etc).

The rendering of tables in a document can be slow, depending on the table type. HTML tables are auto-sized so they can be slower than CALS to render while users are making changes to content within them. Very large tables in general are slow (all table types). The only solution here is to reduce their size, which typically means breaking large tables into pieces then joining them together during output transformation if the final output requires that.

Note that the issues above generally don't apply to Plain Text view as most of the features mentioned won't function in that view, or if they do they function in a much simpler way.

Reply

[PaoloS]

Hi Derek,
thanks for the comprehensive reply.
Trying to completely reset the css file the problem disappears.

I started to exclude half by half the css rules (binary search) to understand what was causing the problem.
Surprisingly, the para tag (most used) had a display: block; set, and removing it the problem is solved….

But removing the “display: block;” rule the paragraphs no longer go on a new line.
In the ctm file customization I tried to insert the NewLineAfterEnd option but without visual effect.

Reply

[PaoloS]

Update:

It looks like the problem of the display:block; rule occurs only if there are associated margin-top or margin-bottom rules

If i use as workaround the rule es. border-top: 7px solid white; instead margin-top:7px; the issue is reduced

Reply

[Derek Read]

Drawing borders around or having a background-color on very large elements (elements that take up multiple screens) can reduce the editing speed.

Sorry I missed that one. I have had quite a fast computer for a few years now so these issues are very much reduced for me and I have to perform fairly extreme stress tests to see them. In my case the element has to span about 25 screens before I start to notice this issue.

If you are drawing a white border then I suspect you must also have a different background-color set for some parent element. If that element commonly spans multiple screens then that could be contributing.

The colour itself does not matter.

Reply

[PaoloS]

Update…
Users reports that deleting zip files present in the desktop the problem it’s mitigated.

@Derek, please could you report the issue to developer dev teams, zip files presence in desktop create problems in other case.

P.S. Why Xmetal dev team not planning to migrate to V8 javascript engine rather than actual Ms JScript ? Performance will be better.

Reply

[nhu1]

>>P.S. Why Xmetal dev team not planning to migrate to V8 javascript engine rather than actual Ms JScript ? Performance will be better.

In short, because V8 does not support COM/IDisptach/IActiveScript.
In order to use V8, the entire API binding has to be re-written. All the existing scripts are not likely going to be run under V8 by default (e.g., if the scripts use new ActiveXObject(…) or XFT forms or winforms or wpf).

The task is too big to consider at present.

Ning Hu

Reply

[Author]

Posts