I just purchased Super Text Mesh and it's bringing the editor to a crawl.  The slowdown depends on the number of characters in the text field.  It's not too bad with just a few words, but it gets quite slow after a few sentences and after a few paragraphs it's completely unusable (takes over a minute just to change the text color or load a prefab with Super Text).

I'm using Unity 6000.0.27f1.  All Super Text settings are default and I'm using newly created Super Text objects.  I'm using a single Screen Space Overlay canvas and don't have any slowdown issues with TMP.

When I add the script it doesn't automatically add STM pagination.  If I add it manually or click Manual Set Up it adds one that is disabled and throws null errors because overflow text isn't assigned.  Clicking Manual Set Up again sometimes assigns the overflow text, sometimes not.  At that point, it creates a second STM clone with an exact copy of the first one's text.  After this happens, the original's text is stale and doesn't update when I change the text in the text box.

I copied your settings and wasn't able to get it to automatically create/destroy/assign text to STM objects.

It's not supposed to do it automatically on being added, but it will do it after any default value is changed or text is changed on the mesh - (The default assigned values on a new instance of the script will no nothing - autoLineCount is set to false, lineCount is set to 1) I did it this way because the code called upon OnEnable() and OnDisable() wouldn't hook into STM properly if run on the same frame- so I figured two birds one stone - if the script when created is in a non-automatic state and requires set up, the action of setting it up will finish the enable process once the text mesh is edited. So... it's by design!

There shouldn't be any null errors though, I can give that another look after dinner...

Your "lines per text mesh" value is 31, try changing that, if it's higher than the amount of lines, no additional meshes will be created.

Here's what I'm doing:

1. Create Super Text via UI --> Super Text
2. Change text to "Test"
3. Add STM Auto Split to Super Text
4. Click Manual Set Up --> null error

At this point, the text field is stale and doesn't update the rendered text when changed.  I tried manually assigning overflow text in the STM Pagination component and clicking Manual Set Up again, but it's completely unresponsive to text changes at this point.

Following these steps, and I cannot reproduce that... can you send me the text from the error you're getting?

NullReferenceException: Object reference not set to an instance of an object STMPagination.Awake () (at Assets/Extensions/Clavian/SuperTextMesh/Sample/Pagination/STMPagination.cs:13) UnityEngine.GameObject:AddComponent() STMAutoSplit:SetUp() (at Assets/Scripts/STMAutoSplit.cs:108) STMAutoSplitEditor:OnInspectorGUI() (at Assets/Scripts/STMAutoSplit.cs:30) UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr, Boolean&)

NullReferenceException: Object reference not set to an instance of an object STMPagination.OnDisable () (at Assets/Extensions/Clavian/SuperTextMesh/Sample/Pagination/STMPagination.cs:38) UnityEngine.GameObject:AddComponent() STMAutoSplit:SetUp() (at Assets/Scripts/STMAutoSplit.cs:108) STMAutoSplitEditor:OnInspectorGUI() (at Assets/Scripts/STMAutoSplit.cs:30) UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr, Boolean&)

Oh right, I forgot I updates STMPagination with some safeties for this... sorry! Ok here's the updated script for that: https://pastebin.com/TDAy7Fc0
If *this* doesn't work, it's probably something with script execution order so will need another way around that.

OK, no more errors or stale text, but pagination still doesn't work.  No STM objects are created.  Tried with both manual and auto line counts.  Overflow text still isn't assigned.  Am I supposed to manually assign it to something?

Once the script is added, clicking "Manual Set Up" should create more STM objects as siblings of the first and automatically attach and set up STMPagination scripts on them - Keep in mind, if "autoLineCount" is on and the amount of text is only enough for one line, no text meshes will be created. If "linesPerTextMesh" is too high, no text meshes will be created. If "lineCount" is 1, no text meshes will be created. The script just formats STM objects and assigns STMPagination scripts automatically, so please send me a screenshot of the inspector if you're still having issues with it.

Alright, I got it to work by turning on auto line count and then clicking manual set up.  I'm confused by the line count field... if it's just a total count of the number of lines of text, shouldn't it be read-only?

Unfortunately it seems to be even slower when using the auto pagination.  I'm not sure it's working correctly - the behavior I see doesn't make sense to me:  it creates a bunch of STM objects and each one has progressively fewer words than the last.  So the rendered text only appears once, but the overall text seems to be duplicated a bunch across several STM objects.

To give a non-concrete example:  if the original text is "One Two Three", then the first clone would have "Two Three", the second has "Three", and then there's a few empty ones as well.

It's just a script for setting up pagination - if you assign the value yourself it'll make that many text meshes - if it's setto auto it'll make as many as needed.

But OK good to know, this means it's got to be something with editing a prefab STM object for sure... I will dig into this more tomorrow!

I admittedly have little experience with serializedObject - I've always used Odin's SerializedScriptableObject and saved them to assets for things like this (and never had any performance issues, even with huge amounts of data/changes).  My hunch is that trying to do all of these updates in OnInspectorGUI is causing the issue, due to Unity's poorly optimized editor code (I have run into similar performance issues with editor text in the past, though not to this degree).

Your new workaround component would work for editing the actual text, but changing other text properties would still lock up Unity, right?  What if you made the actual text box its own separate editor that sits on top of the existing STM editor?  That way you still have everything in one place but the main STM editor isn't bogged down by the actual text.

Hm, I *could* probably make it be like a pop-out inspector just for editing the text property (like the popout text data editor) but from a UX perspective, that's really just about the same as the extra component I wrote anyway...? Both would solve the performance issue in the inspector by having a different text box to type into, while hiding the original. Now, I *could* add a toggle for hiding the text box on the base inspector for this, like the different foldouts for sections on the STM inspector! So if you have a large amount of text, you can just collapse that part of the inspector? I can test later if that has a performance boost!

So I'd really like to fix this properly, but ultimately is seems to be a Unity bottleneck issue, I've got a fix already which could potentially lead to a more permanent fix down the line, and the issue is editor-only in a very specific scenario... so I *think* this workaround is acceptable for now? 

I'm curious about your actual in-game use for this, by the way! Because I figure... once the prefab is set up, wouldn't new text be sent to it via a script in-game anyway? I'm very used to all text in games being stored in a dialogue manager rather than on any prefab instances, so I'm wondering if besides the fact I *want* to fix it... if it's an issue Unity has had since 2020... is there any *need* to if there's a working solution and Unity's own issues can't be pierced?

The problem with your current workaround is that, while it does make editing the actual text fine, changing any of the text properties still causes a lockup.  I'm actually finding that leaving the main STM editor visible while typing into the STM Text Send hardly makes any difference.

Something to try would be to cache and remove all text in the main text box before modifying any properties and then restore the text afterwards.  In fact, if this happens quickly enough, it could be seamless enough that the user wouldn't even notice.

As for my use case, I just want to be able to type rich text and be able to immediately see how it will look in-game for:

1. Tutorials and in-game wiki pages: this is where the really long texts are
2. Tooltips and card descriptions: these can be a up to a paragraph or two.

It's somewhat usable for tooltips and cards (though far from a great user experience); and pretty much unusable for tutorials and wikis.

Franky speaking, the reason I bought STM was because I determined it would take too long for me to fix the bugs in my own rich text system; but if I have to deal with super slow performance and/or incomplete workarounds I'd rather just take the time to get my own system working properly.

So I guess it depends on how much time you're willing to spend fixing this (I'm quite surprised I'm the first person to report it, by the way - I would think you'll get a lot more users running into this as people upgrade to Unity 6).  If you think it's a niche use case and not what the asset was designed for and you don't want to take the time to fix it, I understand - I'll just refund it and look for other options.  If you are willing to fix it, though that would be great, because it does seem like a really complete text solution; but the fix will need to be more comprehensive than the workarounds you've provided thus far.

Tried hiding the text box like I suggested but yes, the rest of the inspector still runs slow when edited. So it's unfortunately got nothing to do with the visibility of properties, but ApplyModifiedProperties() itself.

"Removing all text in the main box before modifying properties and then restore text afterwards" just does not work, unfortunately. There are two ways to display the text box in the inspector:

EditorGUILayout.PropertyField(serializedObject.FindProperty("_text")); 
stm.text = EditorGUILayout.TextArea(stm._text);

The way these work is basically... the TextArea() function is both what displays the text in the inspector, and returns the string as modified by the player. It is impossible to display editable text to the player without this. I tried variants on this approach too, and it is unavoidable, if the text is edited directly and then marked as dirty so the value actually saves, the slowdown happens.

This unfortunately seems to be an issue with Unity's prefab system (text outside of an edited prefab is just fine to edit), and while I will keep thinking on this issue, I cannot think of any perfect workaround. If there is a solution, it will come to me later.  This really really feels like a brick wall situation to me, and I can't figure out a way through at the moment, but plenty of ways around.

There are other comprehensive approaches which may be better-suited for your use-case:

1. A dialogue manager.

Instead of keeping text on the text mesh objects, they are stored elsewhere - a .txt file, a dialogue manager script, etc. Then, instead of showing specific overridden prefabs, load text to the prefab/object as needed in-game.

2. Presets over prefabs.

This is just a text renderer, so it's easy to configure one object to look exactly like another, so why use prefabs in the first place? I have a w.i.p. script that can remember settings for a given STM object (text size, color, material, etc) and easily share that between other STM objects that also have this prefab. I'm just using it internally right now, but if you wanted I could polish that up and send it your way. (The UX needs improvement, it otherwise works fine) It works by having multiple STM objects share a preset scriptableObject, and those settings on the preset can be updated later on. I was thinking of including it with the asset sometime.

I'm going to keep thinking on this issue, but it really seems like a Unity problem... It has a traceable date that it became an issue for people, and I see people talking about the issue generically on forums for the last 5 years with the generally-accepted solution just being "unpack your prefabs". I also personally cannot recommend storing your in-game wikis, tutorials, and tooltips directly on prefabs for anything outside of a jam game. (One mistake with prefabs and a large amount of data can be lost from prefab instance overrides) I *developed* STM for users like you, so I would really truly like to solve this, but I just can't see a direct solution at the moment and can only offer my own experience with Unity. So of course I am willing to fix this, I just can't think of any possible solution at the moment short of getting in contact with Unity to see what's going wrong. If anything comes up, I will of course implement it asap.

I do have a UI Manager that handles standardized text (no special formatting and standard headers, icons, etc).  The reason I want to have long rich text for other things is that the formatting is not standardized.  Size, location, and number of headers... inline icons and special formatting... things like that where just having a set of standard prefabs for each template with fixed header locations and etc and then injecting text into them doesn't really make sense.

Now, I suppose as a workaround in my case, since tutorials and wikis are one-offs I could just store them right in the scene instead of using prefabs.  The drawback there is that if I want to change the general appearance of my text containers I'd have to do it one-by-one instead of just changing a base prefab.

So I guess I would end up with a system where I just mock up each long text in the scene, then have a script that extracts and stores that text.  Then at runtime, instantiate the prefab and inject the text.  I'd also have to build an editor interface for displaying and loading each text into the mock up container (for later editing). Not the workflow I was hoping for, but once set up it should require minimal maintenance - I'll give it a try this week.

Have you considered reporting this regression to Unity?  I know it's often a waste of time, but in my experience, they've actually been pretty quick about actioning bugs and regressions in Unity 6.

Ok I see, that makes sense as a use-case... The "changing the general appearance of text containers" bit sounds a lot like my presets script I wrote though - will try to clean that up and send it over soon since I think that could fix stuff when it comes to formatting.

I'll try writing a report soon - looks like there's enough evidence with the forum threads I found to make it worth a report - with any luck someone will just know what the hell I'm doing wrong and point it out, but maybe it is some caveat of UGUI... Will try that soon. 

OK, I managed to clean up my preset scripts with a custom inspector!

STMPresetController https://pastebin.com/pZymy31R

STMPreset https://pastebin.com/9mXe2emT

Add STMPresetController to whatever gameObject has STM on it and you want to control with a preset. There's a "NEW" button that will create a new preset based on the settings of the STM object.

Once a preset is assigned, "Copy Super Text Mesh to Preset" will re-apply settings to the preset as if it was newly created, "Paste Preset to Super Text Mesh" will take the settings on the preset and send that to the attached STM object, and "Paste Preset to ALL" will do the same but to every STM object in the scene. I was going to make this automatic, but it's just an editor tool so it would be impossible to run on presets not open until they're open... So I *could* have it run during runtime OnEnable(), but for now it's just there to apply multiple settings at once.

So... if you had two Preset Controllers in a scene, changed the settings on one and pressed "Paste Preset to ALL", the changed settings will apply to all STM objects with the same STMPreset assigned to them.

The settings are limited to Font, Size, Quality, Filter Mode, Line Spacing, Material, and an option for Base Offset at the moment since those are what I think is most relevant to this, but it could be expanded later.

I'd forgotten how integrated my tutorial system is with prefabs (it relies on assets for initialization of a lot of things).  So I decided that rather than redesign the whole system, it would be easier just to have an unpacked tutorial prefab in the scene that I use to mock up the text, then copy and paste that text into each prefab.  It's a bit higher maintenance since I have to replace that unpacked prefab any time there's a change to the parent (also changes to the parent are still super slow), but overall it should take a lot less time that rebuilding the system to not use prefabs.

Your preset script is cool, but having things in prefabs allows me to change ALL aspects of an object including its UI elements, not just the text itself.  I appreciate all of your effort on this, and if I can get the rich text tags to work as needed I will stick with STM, with the hope that these performance issues (both with prefabs and long text in general) will be fixed in the future.

Regarding rich text tags, I was under the impression that you can create your own custom tags; but after taking a closer look at the documentation I only see instructions on how to edit existing ones or add colors.  How would I go about implementing my own tags?  For example:

1.  <h1> to increase relative font size and make the text bold?
2. <ol> / <ul> / <li> Ordered and unordered (bullet) lists / list items?

It's OK if I have to define my own logic for generating the final text (or if you're using TMP under the hood, that's even better, since I already have logic for converting these tags to TMP tags).  If you could just point me to the relevant code/assets that would be great.

Ok cool, glad you have a working solution! Once again, sorry for the performance issues, but I still have not been able to come up with any other workarounds - will keep my eyes open though.

Good point, the custom text tags in STM refer to the tags like <w=MyCustomWave>, so maybe I should redo the language on this... I've got two solutions already though:

1. Use the voices tag (<v=myVoice>) which just inserts a pre-made string configured in the text data editor, which can contain other tags. So... "<v=h1>" could become "<s=1.2><b>" if set up this way.

2. If you look at the "Links" example scene, I have a more thorough example of a truly custom  tag. It uses STM's preparse event to inject a custom tag with regex. It takes a string like "<link=Label>" and turns it into <e2=link,label> which is then further sent to the custom event system. So, turning this into a string replacement script for your purpose would be easy! "<h1>" can turn into "<s=1.2><b>".

That said, lists will be a bit more work. STM's formatting may look like HTML, but it is not HTML. There isn't an internal numbering system for lists or anything like that, it's just a renderer. I'd personally just write stuff by hand, but you could  write a custom tag in this way that would do the following:

*Find the start and end tags' position ("<ol>" and either "</ol>" or the end of the string)

*Run replacement code for all text between these tags, so after every linebreak, insert a string for the numbering system. (eg 1. 2. 3.) There should be a special situation to also insert on the first index if the tag is not followed by a linebreak, and to NOT insert on the final linebreak if the tag immediately follows it.

*Remove original tags. also make sure to update the indices as the sting updates.

I am not running TMP under the hood, this is a different asset that began development before TMP was purchased by Unity. I hope this info helps!

Thanks.  Instead of using that event I decided to just modify the main ParseText function to call my own preparse function, since I want these tags to be applied globally.  It works great - I implemented my custom tags as well as my list parsing functionality.

The only issue I'm running into is indentation and vertical spacing.  I need to add indent to each list item based on its nested depth (including line wraps) and I need to add a bit of vertical space (a fraction of a newline) after each heading.

Are there any tags for accomplishing these things that respect the actual text size (font size as well as any size modifiers)?  If not I suppose I'll have to move my tag parser call deeper into ParseText so that I can pass in the calculated text size.  I notice you're using some manual string indexing though which is why I'm a little hesitant to go messing around deeper in that function.

Right, that's another valid way to implement tags.

There's the <indent=x> tag, but it just uses a non-relative value like the <size=x> tag. I could add an <indentRelative=x> tag (probably with a shorter name) for that, or if you're already adding custom tags, you can modify the code to multiply by size.

Another option would be making an empty quad (with a full transparency texture), which would scale up and down with text naturally, and let you control the indent size from the width of the quad. So... that's an existing tag that would let you do this!

Does this information help?

I actually just now got everything working.  I used the indent tag multiplied by font size as you suggested, and for heading space I used y offset.  Everything appears to be working now.  Thanks for all the help and for looking into the performance issues - hopefully Unity gets back to you with something helpful.  From my perspective, the performance issues are the only thing holding this asset back from being a complete and very versatile TMP replacement.

Thank you for your patience with me, will send Unity something soon - because yeah it is quite odd that other text renderers aren't having this issue, while it's been a reported issue for other custom inspectors for at least 5 years... Not sure if it's an internal code thing or something I'm just not understanding. So thank you very much for the kind words!