Delta Rendering

View-based delta rendering is used to improve the performance of user interaction in complex applications when only a part (view) of the displayed page has to be updated. Only the view that has been changed is newly rendered. If several views have been changed, the view rendered is the one containing the changed views and any views beneath it, which means that only a certain part of the page is replaced. For programming, this means that you should avoid unnecessary context updates, and avoid making changes to view elements.

Some of the advantages of delta rendering include:

Being able to open the context menu quickly
Being able to trigger portal navigation quickly and open a separate window
Faster scrolling and faster user interaction when working with ALV tables
Being able to accelerate those actions that only have an impact on part of the screen

As of Enhancement Package 2, all Web Dynpro applications run with delta rendering by default. You can activate or deactivate delta rendering for an individual application with the wdDeltaRendering application parameter, as follows:

Setting delta rendering using application parameter WDDELTARENDERING
or
Setting delta rendering using URL parameter sap-wd-DeltaRendering

Procedures

Procedure for the URL Parameter

Call the URL of the application for which you want to activate delta rendering.
Activate delta rendering by adding URL parameter sap-wd-DeltaRendering with value ON to the URL.
Choose Enter.

Note Note

Note that URL parameter sap-wd-DeltaRendering overrides application parameter WDDELTARENDERING.

End of the note.

Procedure for Application Parameter

In the Web Dynpro Explorer, display the properties of your Web Dynpro application by double-clicking the application.
Choose the Parameters tab page.
In change mode using F4 help for Parameter choose entry WDDELTARENDERING.
Manually insert the associated value ON.
Save your entries.

Implementing Delta Rendering

We recommend you use delta rendering for complex pages on which usually only a part of the page is updated.

Critical for the success of delta rendering are:

The design of each view
Write access is used only to access objects to be updated (context, view elements)

Example	Procedure
A page contains several large `Table`s	Insert each `Table` into a separate view
One page contains a `TimedTrigger` that polls the system for updates	Insert the `TimedTrigger` into a separate view Note Using a `TimedTrigger` as polling method may affect performance. End of the note.
A page contains elements that are not supported by delta rendering (see below)	Insert the elements not supported by delta rendering into separate views
A page contains an area that is to be updated due to an `InputField` `onEnter` or `onChange` event	Insert the elements to be updated and the triggering `InputField` into a separate view

Delta Rendering Functions

The purpose of delta rendering is to update only the area of the displayed page that has been changed by the application. The granularity for these updates is a view. Only one area is updated at a time; the innermost view of all changed views is refreshed accordingly. In the most unfavorable case this is the top view of the application.

To determine which views have to be updated, any changes to the Web Dynpro programming interface that could lead to a change in the visualization of a view are registered:

Navigation
Change to the UI element tree
Personalization change
Changes to Context and ContextNodeInfos
Messages

No check is made to determine whether these actually result in a changed value. A simple call to a changing method results in the view being updated.

User interaction with screen elements also results in the view being updated.

Note Note

Context Mapping

When using context mapping, note that a change operation to a mapped context node and its subnodes results in an update to each view that maps to these nodes. It is irrelevant whether the subnodes or attributes in the development environment have been copied to the mapping or not.

End of the note.

Effect of Delta Rendering

Since delta rendering is applied before the "costly" rendering process, in some scenarios, you can achieve significant performance improvements on the server as well as in the Web browser.

Restrictions

The following UI elements are not (yet) supported by delta rendering:

TimedTrigger
Gantt
Network
InteractiveForm
OfficeControl

For this reason a view with one or more of these UI elements is updated with the roundtrip.

Possible Side Effects

If an application uses very fine-granular change operations (for example SET_ATTRIBUTE calls for each field of a context node instead of BIND_TABLE), delta rendering can lower performance.

Delta rendering errors may occur due to JavaScript errors when calling document.getElementById(...) after a server roundtrip, or because screen areas have not been updated. If errors occur, see SAP Note 1021981.

Tips and Tricks

Delta rendering invalidates a view as a result of a changing context or UI element operation. This happens regardless of whether the actual status was changed or not. The invalidation leads to a new rendering of the view.

In the following two scenarios a check is introduced to ascertain whether the status was actually changed:

Check for changes in values in CL_WD_UIELEMENT=>SET_ENABLED and SET_VISIBLE
When methods of this class or of classes inheriting from this class are called, the view is invalidated only if the value of ENABLED or VISIBLE actually changes too.
Check for changes in values in IF_WD_CONTEXT_NODE=>SET_ATTRIBUTE and IF_WD_CONTEXT_ELEMENT=>SET_ATTRIBUTE
When these methods are called, the view is only invalidated, if the value actually changes, and the following criteria are met:
1. A value is specified in attribute VALUE
2. A static attribute is set.
3. The ABAP types of VALUE and the attribute are the same, or both types are C or STRING.

More Information

For more information about delta rendering and the trace tool, see Tuning and Troubleshooting.