diff --git a/src/db/db/gsiDeclDbLayout.cc b/src/db/db/gsiDeclDbLayout.cc index d08a06a2d..42d02f5f6 100644 --- a/src/db/db/gsiDeclDbLayout.cc +++ b/src/db/db/gsiDeclDbLayout.cc @@ -949,8 +949,7 @@ Class decl_Layout ("db", "Layout", "\n" "This constructor specifies a manager object which is used to " "store undo information for example. It also allows one to specify whether " - "the layout is editable. In editable mode, some optimisations are disabled " - "and the layout can be manipulated through a variety of methods.\n" + "the layout is editable. For a discussion of editable vs. non-editable layouts see @Editable and non-editable layouts@.\n" "\n" "This method was introduced in version 0.22.\n" ) + diff --git a/src/lay/lay/doc/about/editable_layouts.xml b/src/lay/lay/doc/about/editable_layouts.xml new file mode 100644 index 000000000..2127cb665 --- /dev/null +++ b/src/lay/lay/doc/about/editable_layouts.xml @@ -0,0 +1,85 @@ + + + + + + Editable and non-editable layout objects + +

+ Layout objects (see ) offer two basic modes which may make a huge + difference is some cases: +

+ + + +

+ Non-editable layouts basically spend less memory on providing annotation information so certain + safeguards are not present. This makes coding of scripts more challenging. Non-editable layouts + internally maintain the shape repetitions and are therefore significantly more memory efficient + as editable layouts. On the downside, you cannot take out a shape from such an array and manipulate + it individually. This is the reason, this layout type is called non-editable. +

+ +

Restrictions in non-editable mode

+ +

+ Functionality not supported in non-editable mode: +

+ + + +

+ Adding shapes to a shape collection (per-cell layer) is possible in non-editable mode, but this may + invalidate other shape objects (see ) from the same shape collection. + It's not safe to keep shape objects while manipulating shape collections. An application crash + may follow when trying to access such invalid shapes. +

+ +

+ In non-editable mode, when iterating over shapes all individual members of the + shape array are traversed. While this is allowed, this basically means shape array + expansion with a potential impact on runtime and memory consumption. Some operations + which involve shape-by-shape operations (e.g. boolean operations) will also expand shape arrays. + Full-layer copies or moves - also on cell level - will preserve the shape array nature and + may be much more efficient in non-editable mode. +

+ +

+ When manipulating instances, non-editable layouts are more susceptible to + iterator corruption. Bulk manipulations of instances should be avoided. Instance objects (see ) may become invalid + when the corresponding instance collection of the cell is manipulated. Accessing invalid instance objects may crash the application. +

+ +

+ In short, these cell instance operations are considered safe in non-editable mode: +

+ + + +
+ diff --git a/src/lay/lay/doc/about/index.xml b/src/lay/lay/doc/about/index.xml index f5c93bbe2..489c80c0b 100644 --- a/src/lay/lay/doc/about/index.xml +++ b/src/lay/lay/doc/about/index.xml @@ -28,6 +28,7 @@ + diff --git a/src/lay/lay/layHelpResources.qrc b/src/lay/lay/layHelpResources.qrc index 12e304bcb..e67575d99 100644 --- a/src/lay/lay/layHelpResources.qrc +++ b/src/lay/lay/layHelpResources.qrc @@ -47,6 +47,7 @@ doc/about/lvs_ref_global.xml doc/about/lvs_ref_netter.xml doc/about/packages.xml + doc/about/editable_layouts.xml doc/manual/adjust_origin.xml