In UI5, the rendering process involves creating the visual representation of user interface elements, and it can be a resource-intensive task, especially when dealing with complex and responsive UIs. Our performance tests show that the rendering process is one of the most significant factors affecting the performance of UI5 applications. Hence UI5 has introduced various features to improve the rendering and re-rendering process, for example Semantic Rendering.

In the latest release of UI5, there is an innovation in rendering that promises to improve the performance further with reducing the number of redundant re-rerenderings.

To understand this innovation let’s have a look at first how the rendering works in UI5. By default, if a property, an aggregation, or an association of a control is changed, then the control gets invalidated, and the re-rendering process for that control and all its descendant controls start. That means child controls re-render together with their parent even though there is no DOM update necessary.
The new rendering reuses the control’s DOM output and prevents child controls from unnecessary re-renderings while they are getting rendered by their parent.
To activate the new rendering, the “apiVersion” property of the control renderer must be set to 4. This new marker lets the RenderManager know that a control’s output is not affected by changes in the parent control. Of course, this is only possible if there is a good rendering encapsulation and no parent state dependency.

For example, let’s say you have a parent control called “ParentControl” that has a child control called “ChildControl”. ChildControl has its own properties, aggregations, and associations, and its output is only affected by them. By setting the apiVersion to 4 in the renderer of ChildControl whenever a property of the ParentControl is changed during the rerendering process, the RenderManager will check the apiVersion marker of the ChildControl’s renderer. If it’s 4, the RenderManager skips the rendering of the ChildControl, leading to faster performance and a smoother user experience.

However, to ensure compatibility with the apiVersion 4 marker, certain prerequisites must be fulfilled. First, all the prerequisites of the apiVersion 2 marker must be fulfilled by the control. Most importantly, the control renderer must maintain a proper rendering encapsulation and render only the properties, aggregations, and associations that are specific to the control. The renderer should not reference or depend on any state of the parent control or any other external element.

Please note that there is no apiVersion 4 control available in UI5 now. This will be done step by step in up-coming releases, but you would like to see some results, wouldn’t you? Then let’s start to build a few custom controls, once with apiVersion 2 and once with apiVersion 4. In my testing scenario I would like to stress the RenderManager, and I will first insert 1000 list items to the list and then change only the header of my list control. To measure the results, we need to know the frame rendering stats, and Chrome developer tools already have exactly what we need. To open the frame  rendering stats, open the Rendering tab and enable the Frame rendering stats checkbox, then look at the statistics in the top corner of the page.

Now is the time… Here is the apiVersion 2 and here is the apiVersion 4 test case. Please note that the only difference between these tests is the apiVersion marker. If you do not want to hear noises from your computer’s fan,  here are the test results we get.

If you now want to convert your custom controls to apiVersion 4, then please make sure that you fulfill the apiVersion 4 prerequisites. Here you can find the apiVersion 4 contract.

We are excited to see the impact that the apiVersion 4 marker will have on UI5 performance.