Following relations between the size of the text area and the screen update performance are feasible:
The number of text signs within the area may certainly affect the performance. You can imagine, for every text sign some OpenGL API calls are necessary and every API call will contribute to the total runtime of the screen update.
Other graphical objects lying behind or in front of the text area may also affect the performance. When the content of the text area is scrolled, then the part of the screen covered by the text area needs an update. This means, graphical objects enclosed within or intersecting the area are also drawn. The more graphical objects involved in this update the more calls to the OpenGL API.
Without having seen your project, it is difficult to determine the possible root of the performance issue. Also not always unproblematic, the OpenGL implementations differ. We observed that different OpenGL driver provide different runtime, or better said different latence time of called API functions. This can unexpectedly impact the performance.
I would suggest to test following:
- In your application with the large text view:
- Assign a very short text (few signs) to the text area.
- Test the performance when you try to scroll the text.
- If the performance is good --> the problem seems to be related to the number of text signs.
- Create a new application containing the large text area only.
- Assign the original text to it as you used within the original application.
- Test the performance again.
- When the performance is good --> the problem is related to other graphical objects lying behind or in front of the text area.
If the tests show that the problem is related to the number of text signs, then I don't see a workaround for it. You will need to reduce the size of the text area.
If the tests show that the problem is related to other graphical objects lying behind/infront of the text area, try following:
- Review your application. May be it is too complicated. It can contain too many nested components with too many embedded graphical views?
- When a complex component lies behind or in front of the text area, and this component impacts the performance, you can set the property Buffered of this component to true.
With Buffered property the component will manage internally a copy of its own appearance. When the screen composition is performed, the buffer of such component is simply copied instead of redrawing all the graphical objects existing within the component.
Regarding your assumption: the Graphics Engine of Embedded Wizard performs the screen updates in three phases. In the first phase, the Graphics Engine collects drawing operations generated by the GUI. In the second phase, the Graphics Engine preprocesses, optimizes and eliminates unnecessary drawing operations. Finally, in the third phase, the remaining operations are executed.
The execution takes place within EwExecuteTasks() function. This function interacts with the underlying graphics subsystem (here OpenGL ES 2.0) and thus peforms the collected operations. The runtime of the EwExecuteTasks() function corresponds directly to the time, which the underlying graphics subsystem needs for the execution of the drawing operations.
Following from this, I suppose the runtime is spent in the OpenGL subsystem.