Linux OpenGL-ES2.0: Slow update of text view when sliding

186 views
asked Jul 27, 2016 in System Integration by m0w
Hello,

i try to use a large scrollable text area (980x440px).

When scrolling i get a framerate of about 2-4FPS. As Soon as i reduce the Size of the text area (540x370) The framerate is totally acceptable again.

Is there any way to speed up the update rate or do i simply have to use smaller text areas?

(My debugging lead me to the assumption, that EwExecuteTasks (in ewgfxtasks.c) produces this slowdown somehow)

Any idea would be greatly appreciated,

Moritz Wagner

1 Answer

0 votes
answered Jul 27, 2016 by Paul Banach
 
Best answer

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:

  1. In your application with the large text view:
    1. Assign a very short text (few signs) to the text area.
    2. Test the performance when you try to scroll the text.
    3. If the performance is good --> the problem seems to be related to the number of text signs.
  2. Create a new application containing the large text area only.
    1. Assign the original text to it as you used within the original application.
    2. Test the performance again.
    3. 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:

  1. Review your application. May be it is too complicated. It can contain too many nested components with too many embedded graphical views?
  2. 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.

commented Jul 28, 2016 by m0w
Hello,

thank you very much for this detailed insight. Indeed the Problem was with underlying ojbects. To be precise: one single image frame overlays the text area, and this made the difference. Now i disabled drawing the interior of the frame and everything is perfect. Sad though, that a frame cannot be set to buffered, this might have solved the problem as well i think.

Thanks to you even huge amounts of text now scroll flawless, thank you very much I'll project this knowledge to the rest of the project, this will surely improve performance at some points.
commented Jul 28, 2016 by Paul Banach

The Bitmap Frame object uses internally a TileBitmap operation, which in turn fills screen areas with multiple copies of a source bitmap. If the source bitmap is very small and the destination area large, then this operation will result in tousends of bitmap copy operations. In the current OpenGL ES 2.0 PP version every copy operation is treated individually causing (in this case) tousends of OpenGL API calls.

We already know this issue and plan to improve the OpenGL ES 2.0 PP so a single TileBitmap operation will result in few OpenGL ES calls regardless of the size of the filled area.

In your current case, you have already disabled the drawing of the Bitmap Frame's interior area. Now you can arrange a filled rectangle object to cover this area to achieve similar effects. Set the color of the rectange to the color of the interior area of the bitmap. This approach is very efficient.

 

 

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...