Flutter Widget Rendering Optimization with Custom RenderObjects and DSL Integration

Background The team experimented with DinamicX DSL to dynamically render Flutter pages. The initial expectation of a simple DSL‑to‑Widget mapping turned out to be wrong: list scrolling was severely janky and frame rates dropped dramatically.

Why native solutions perform poorly in Flutter In native Android/iOS, layout is described by XML or storyboard files. Flutter lacks the concepts of match_parent and match_content , and its Widgets are immutable, causing frequent creation and destruction during rebuilds.

Understanding the three trees Flutter separates UI into Widget , Element , and RenderObject . A simple Opacity widget demonstrates the relationship:

class Opacity extends RenderObjectWidget { ... }

Widget is a lightweight, immutable configuration object. Opacity inherits from RenderObjectWidget and defines two key methods:

RenderObjectElement createElement();
RenderObject createRenderObject(BuildContext context);

Element bridges Widget and RenderObject. During the build phase, Element.updateChild decides whether to update an existing child or create a new one:

Element updateChild(Element child, Widget newWidget, dynamic newSlot) { ... }

RenderObject performs layout, painting and hit‑testing. Example paint method:

void paint(PaintingContext context, Offset offset) { if (child != null) { context.pushOpacity(offset, _alpha, super.paint); } }

Layout optimization in Flutter Flutter performs a single O(N) layout pass. RelayoutBoundary marks nodes whose size changes do not affect ancestors, reducing unnecessary layout work. Conditions include parentUsesSize = false , sizedByParent = true , tight constraints, or non‑RenderObject parents.

Element update optimization Widget.canUpdate checks runtimeType and key to decide if an existing Element can be updated instead of recreated:

static bool canUpdate(Widget oldWidget, Widget newWidget) {
  return oldWidget.runtimeType == newWidget.runtimeType && oldWidget.key == newWidget.key;
}

Custom Widget design Two versions were explored:

First version: all components inherit from a base object and implement a simple build method. This leads to O(N²) layout cost in worst‑case scenarios because every update forces a full tree traversal.

Second version: custom Widget , Element , and RenderObject classes. Three widget categories were defined – leaf widgets (e.g., Image, Text), multi‑child containers (e.g., FrameLayout, LinearLayout), and scrollable lists (e.g., ListLayout, PageLayout).

Handling match_content The parent must layout its children first, then compute its own size. In performLayout the child is laid out with parentUsesSize: true and the size is set from the child's size.

void performLayout() {
  if (child != null) {
    child.layout(constraints, parentUsesSize: true);
    size = constraints.constrain(child.size);
  } else {
    size = constraints.biggest;
  }
}

Handling match_parent When a node should expand to its parent, sizedByParent is set to true and performResize simply assigns the biggest constraint:

void performResize() {
  size = constraints.biggest;
}

Performance results After applying the second‑version design, average frame rate for long lists increased from ~28 fps to ~50 fps.

Current issues & outlook The current implementation always sets parentUsesSize: true for every child, even when unnecessary, preventing full benefit of RelayoutBoundary . Future work will refine this logic, reduce layout passes, and extend the DSL‑to‑Widget pipeline to cover editing, validation, CDN distribution, gray‑release testing, and monitoring.