Optimizing the CGLocalization Window

In the version 1.1 of the tool, I optimized the Add Language and Languages windows. But I left a TO-DO comment in the CGLocalizationWindow class to remember me that the keys must be also optimized.

The mentioned windows where optimized by drawing only a few amount of visible items (languages) inside of the scroll view. I used the code in the next link for the optimization: ScrollView performances with huge number of GUIContents .

For optimizing the keys inside the scroll view of the CGLocalization window was different because keys can have a variable height. The language rects use the same height, and the code in the above link is for fixed height items.

After thinking a lot, I arrived to the conclusion that the scroll view and all the keys have a Rect used for drawing. Why not to try to check if the rects overlaps? If the rects do not overlaps, then the key is not drawn.

For drawing a key, two rects are needed:

1. Normal Rect: Used to draw it inside the viewRect.
2. Global Rect: Used to check if it overlaps with the position rect of the scroll view. It's equal to the normal rect but I rested the scrollPosition to the globalRect.y component. The two top toolbars height were added to match the position.y.

If the globlalRect do not overlaps with the position rect, then the key is not drawn and a blank space is left. This way only the keys visible to the user are drawn, so that, a Language can have any amount of keys without affecting the performance of the Unity Editor!!!

After this optimization, then a big error arose. Every time I added a new key or changed the window size, this nice error message appeared on the console many times:
     ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting

After reading the answer by Bunny83 in the above link, I used the suggestion in his own comment: "So SOLUTION is that in "Layout" phase you set flags/bools, and if that flags are set then you paint in "Repaint" phase".

The implementation removed the error messages, but then, the keys were not drawn for approximately 200 milliseconds each time I added a new key from the toolbar. Then I read the How GUI system works in the Bunny83 answer and specially the GUI vs GUILayout section. Here he mentions that "The normal GUI functions completely ignores the Layout event". So that, I removed the previous implementation and implemented the drawing of the keys components by using the GUI class and everything works perfectly.

This optimization will be included in the next update of the tool.

Edit (2020-02-06)

After testing the optimization today, I noticed that while editing a name or string value, if we scroll up or down, the editing (or focused) edit text is also scrolled up or down!!!!!! And when we stop scrolling and hit Enter or change the focus, the text is copied the text field placed on the position where we stopped scrolling. I reproduced the bug in a small window. See the next figure:

Source code here

These are the quick solutions to this bug I made until now:

• For solving the text duplication I changed from EditorGUI.DelayedTextField() to EditorGUI.TextField()
  (Comment the line 50 and uncomment the 53 in the above window code and test it by yourself)
• For solving the scrolling issue I just defocus any editing text while scrolling.

I am still investigating why this is happening. If you have a suggestion or solution, let me know in the comments.