drawing performance realtime

[jjoe64]

500 items

[sakulstra]

👍 let me know if i can somehow help here :)
(on my p780 it's already laggy with more than 300 items)

[TorsteinBerge]

I have problems with the performance (real-time graph with 600 items). Method profiling may indicate that the problem is related to calculation of max/min y-values in BaseSeries.java.

Can introduction of MinMaxPriorityQueue be a solution? For instance something like this:

private class ValueRangeHandler {
    private class Value {
        public double value;
        public Value successor;
        public Value(double newValue) {
            value = newValue;
            successor = null;
        }
    }

    private class ValueComparator implements Comparator<Value> {
        @Override
        public int compare(Value lhs, Value rhs) {
            if (lhs.value < rhs.value) {
                return 1;
            }
            if (lhs.value > rhs.value) {
                return -1;
            }
            return 0;
        }
    }

    private int mCapacity;
    private Value mOldestValue;
    private Value mNewestValue;
    private Comparator<Value> mComparator;
    MinMaxPriorityQueue<Value> mQueue;

    public ValueRangeHandler(int capacity) {
        mComparator = new ValueComparator();
        mQueue = MinMaxPriorityQueue.orderedBy(mComparator).maximumSize(capacity).create();
        mCapacity = capacity;
        mOldestValue = null;
        mNewestValue = null;
    }

    public void addValue(float value) {
        Value newValue = new Value(value);
        if (mNewestValue != null) {
            mNewestValue.successor = newValue;
        }
        else {
            // First value added, set this as the oldest.
            mOldestValue = newValue;
        }
        mNewestValue = newValue;
        if (mQueue.size() == mCapacity) {
            Value valueToRemove = mOldestValue;
            mOldestValue = mOldestValue.successor;
            mQueue.remove(valueToRemove);
        }
        mQueue.add(newValue);
    }

    public double getMax() {
        if (mQueue.size() > 0) {
            return mQueue.peek().value;
        }
        else {
            return 0.0;
        }
    }

    public double getMin() {
        if (mQueue.size() > 0) {
            return mQueue.peekLast().value;
        }
        else {
            return 0.0;
        }
    }

    public void clearValues() {
        mQueue.clear();
        mOldestValue = null;
        mNewestValue = null;
    }
}

[Jordandev678]

The problem is indeed related to calculating the min/max values.

In my case every point changes between updates so I'm using GraphView.resetData for the updates. It spends most of its time in GraphView.onDataChanged which in turn spends almost all of its time in Viewport.calcCompleteRange.

A cursory look says there is no particular need for any of this work to be done on the UiThread - the only thing stopping it at the moment is the call to invalidatein GraphView.onDataChanged.

Changing this to postInvalidateallows it to be called from worker threads and avoid it freezing the UI thread.

I'm currently using a version I made with that change and so far its working flawlessly. In fact before even moving the resetData call to a worker thread I saw immediate speed improvements just from the change to postInvalidate as (I assume) it offloaded the drawing work onto the next frame cycle instead of piling it on the already overtaxed one. Incidentally this also indicates that the change wouldn't cause any backwards compatibility issues.