Widget API: Region:SetPoint/Exponential:time
Region:SetPoint » Exponential time
← Widget API ← Region < time
As of approximately v1.11, creating a chain of relative positioning, where more than one SetPoint() call is done on a number of frames (i.e. the next frame has its size and' position dependent on the previous one), causes exponential execution time during SetPoint() calls.
Multiple chained SetPoint() calls causing exponential execution time
Consider the below code, which creates a stack of frames, each 100 pixels wide and 10 pixels high, with 2 pixels of spacing between them:
first = CreateFrame("Frame", UIParent); first:SetPoint("TOPLEFT", UIParent, "BOTTOMLEFT", 700, 500); first:SetWidth(100); first:SetHeight(10); prev=first; for i=1,NUMFRAMES do f = CreateFrame("Frame", UIParent); f:SetPoint("TOPLEFT", prev, "BOTTOMLEFT", 0, -2); f:SetPoint("TOPRIGHT", prev, "BOTTOMRIGHT", 0, -2); f:SetHeight(10); prev=f; end endTime = GetTime();
Timing results for different numbers of frames chained:
19: 0.3s 20: 0.6s 21: 1.3s 22: 2.6s 23: 5.2s 24: 10.4s 25: 20.8s
- The original snippet feeds information for the same edge (TOP) twice, but the below code, which avoids doing that, has the exact same results:
f:SetPoint("TOPLEFT", prev, "BOTTOMLEFT", 0, -2); f:SetPoint("RIGHT", prev, "RIGHT", 0, 0);
- Referencing the same corner in both calls also has the same results:
f:SetPoint("TOPLEFT", prev, "TOPLEFT", 0, -12); f:SetPoint("TOPRIGHT", prev, "TOPLEFT", 100, -12);
Solutions
- However, chaining only ONE SetPoint from object to object, and referencing the first object for the second SetPoint, executes faster than GetTime() can measure even for dozens of objects:
f:SetPoint("TOPLEFT", prev, "BOTTOMLEFT", 0, -2); f:SetPoint("RIGHT", first, "RIGHT", 0,0);
- This code also executes in "0 seconds":
f:SetPoint("TOPLEFT", prev, "BOTTOMLEFT", 0, -2); f:SetWidth(100);
Timing the two problematic SetPoint() calls, they both take the same time (i.e. 1.3s each on the 23rd loop). Nothing else in the loop is taking any discernible amount of time.
--Mikk 02:49, 19 August 2006 (EDT)