Speed up QuadBatch.addQuad()

Al_Birdie

I'm currently developing a Starling chart engine and right now I'm in the process of implementing a candle stick chart.
It is already finished but I'm not too satisfied with the performance, hence I'd like to reduce the time it takes to draw the chart a little. I'm already down from 22ms per draw to 12 but that is still a lot compared to a line chart, which takes only 2ms.
Note that the 12ms is for a data set of 500 items. Naturally, less items can be drawn way faster.

This is how I've implemented it;
Each candle consists of two Quads, one for the high-low line, the other one for the open-close bar (which boils down to 1000 quads being added to the batch in every draw).
After being colored and sized to the correct values, they are added to a QuadBatch.
The QuadBatch itself is being reset every time the chart is being re-drawn.

The code for that basically looks like this:

if(_closeWC < _openWC) {
    _lineQuad.color = _valueQuad.color = negativeCandleColor;
    _valueQuad.y = _openDC;
    _valueQuad.scaleY = _closeDC - _openDC;
} else {
    _lineQuad.color = _valueQuad.color = positiveCandleColor;
    _valueQuad.y = _closeDC;
    _valueQuad.scaleY = _openDC - _closeDC;
}

_valueQuad.scaleX = _quadWidth;
_valueQuad.x = xDC - Math.round(_quadWidth / 2);

_lineQuad.x = xDC -1;
_lineQuad.y = _highDC;
_lineQuad.scaleY = _lowDC - _highDC; 

_quadBatch.addQuad(_lineQuad);
_quadBatch.addQuad(_valueQuad);

The Quads are initialised with 1,1,0xffffff, which allows me to use scaleY and scaleX instead of width and height. Unfortunately I have to set the color, which takes quite some time (with 4 ms in total it actually accounts for 30% of the drawing time) and there is no way to optimise that I guess (setting the vertexColors isn't faster at all, so the for loop in set color doesn't introduce a measurable overhead).
So it comes down to _quadBatch.addQuad(). Each call to that costs about 2ms, so it is quite expensive as well.
Is there any way to speed that up? I'm not really sure what to make out of isStageChange() which is mentioned in the asDoc for addQuad().

I'm also interested if a Quad is the right object to use here. I recon it is the fastest already, isn't it?

Any input on how to speed things up would be highly appreciated.

joshtynjala

I would probably try to separate each candlestick into a separate QuadBatch (probably with batchable set to true). If a candlestick isn't updated, it's QuadBatch won't need to change, which should save on the number of Quads being added, I would think.

Al_Birdie

Well, the thing is, when you go through the data (there is a slider at the bottom that lets you specify the start and end index of the range you want to see, basically zooming in or out the data), the chart is being re-drawn completely, it therefore needs to create a new candle for every data object in the visible range. So basically the QuadBatch needs to change during every single re-draw. There is no way around that.

Would I still benefit from creating a separate batch for each candle which will eventually get added to the main batch? I reckon that would create a lot of garbage, wouldn't it?

joshtynjala

If there's no way to limit the number of quads added, I don't think there's any benefit to creating separate batches for each candlestick.

Al_Birdie

Ok. I guess I'm done optimising then, or is there any other way to speed things up?
I mean performance isn't bad, this still does more than 30fps on an iPad2 for the maximum amount of data (bespoken 500 items) and when you zoom in, the draw times reduces drastically, but having a little more wiggle room for devices slower than the iPad2 (which apparently still counts as a current device) isn't necessarily a bad thing. 😉

IonSwitz

Hey, Al_Birdie.

Very hard to judge from what you are saying here, but one thing could be to set the
capacity of the quadBatch to something close to the numbers of addQuad you will be doing, after the reset.

When the quadBatch needs to resize, because of overreaching the capacity, it can get kind of tough.

Maybe this is something you already do, and if that is the case, feel free to ignore this 🙂

EDIT: I just re-read the code, and the reset doesn't lower the capacity of the quadbatch, so this is just dumb advice from my end. Sorry.

EDIT 2: How about not scaling the individual quads, and instead zoom in and out of the quadBatch, leaving the quads in place as constants, regardless of zoom factor?

EDIT 3: And WOW, I just checked how expensive Quad.color is. WOW. It's very very expensive. I would definitely suggest to only call set Quad.color when you know that the color has changed. Could you try a "if ( myQuad.color != theColorIWannaSet ) " check before you call the set method of color?

Incredibly costly method

IonSwitz

Also, this could be an addition to the Quad class:

public function setColorChannels(r:Number, g:Number, b:Number) : void
{
for (var i:int=0; i<4; ++i)
mVertexData.setColorChannels(i, r, g, b);

onVertexDataChanged();

if ( r < 1 || g < 1 || b < 1 )
mTinted = true;
else if ( alpha != 1.0)
mTinted = true;
else mTinted = mVertexData.tinted;
}

and this to the VertexData class:

public function setColorChannels(vertexID:int, r:Number, g:Number, b:Number):void
{
var offset:int = vertexID * ELEMENTS_PER_VERTEX + COLOR_OFFSET;
if ( mPremultipliedAlpha )
{
var multiplier:Number = mRawData[offset + 3];

mRawData[offset] = r * multiplier;
mRawData[offset+1] = g * multiplier;
mRawData[offset+2] = b * multiplier;
}
else
{
mRawData[offset] = r ;
mRawData[offset+1] = g;
mRawData[offset+2] = b;
}
}

Running through 50000 quads (alot, yes) and setting the color through:

q.color = 0xFF0000;

takes almost 40% more time than

q.setColorChannels(1.0, 0.0, 0.0);

using these methods. And yeah, they do the same thing.

Al_Birdie

Greetings!

Regarding zooming the QuadBatch, I guess that wouldn't work the current drawing routine we are using. But scaling the Quads really isn't the performance "issue" here, is is adding them to the batch and resetting the batch. But again, there really isn't an issue when it comes to performance as this runs already smooth as butter on the iPad2 for 500+ items (which is more than enough).

Good call on setting the color only when it changed. Sometimes, things are so simple. 🙂
Draw time: -8% for 500 items 😜

Interestingly, the setColorChanges didn't make a noticeable difference (identical draw time for 2000 items). I guess that's just not enough items for this to make a difference.
However, since you've tested it and it does make a difference for lots of quads, you might just ask Daniel if he could merge this into the Starling repo.

Thanks for your help! I really appreciate it.

IonSwitz

I created an issue at the Starling GitHub for this, but as you say, the benefits might not be huge for most types of operations.

Al_Birdie

Since I'm still looking for ways to improve this, I'm resurrecting this thread from the dead. 😉

I just thought about somehow merging the two Quads into a single one, which would cut the amount of Quads being added to the QuadBatch in half.
Would something like that be possible?

IonSwitz

I think the "two in one" thing would be tricky, and improving addQuad seems tricky.

However, what if you create two pools of Quads, one for negative color and one for positive color?

That way, you could be sure to cut the number of set color calls to 0 during rendering, instead you pull the quads from the negatively colored quads if you have a negative value, and from the positive pool when the value is positive?

Al_Birdie

Pooling sounds like a good idea here. Since setting the color still accounts for a pretty substantial amount of render time here, cutting it down to 0 certainly doesn't sound like the worst idea. 😜
Thanks mate, I'll see what I can do.

lokus

Hi albirdie,
Did you manage to implement the chart engine?

I'm also planning to do a candlestick chart and am looking for open source solutions/inspirations.

Couldn't find anything in the web.
Maybe the performance isn't a problem anymore with the more powerful devices rn?