QJsondocument slowness when hooked up to a QSlider

Kris Revi

So i just got the QJsondocument thing working and tested it on a QSlider but damn it's slow, can anyone tell me why?

what this program is controlling is an arduino that has LED's on it and when i slide the QSlider from 0 to 255 i see the LED's SLOWLY ramping up the brightness (it's not happening like "on the fly") if you understand, what causes this? is there anything i can set to make it go instantly?

class software(QtWidgets.QMainWindow):
    def __init__(self, parent=None):
        QtWidgets.QWidget.__init__(self, parent)
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)
        self.ui.Brightnessslider.valueChanged.connect(self.adjustBrightness)

        self.nam2 = QtNetwork.QNetworkAccessManager()

    def doPost(self, toUrl, tojson):
        try:
            print(tojson)
            document = QJsonDocument(tojson)

            request = QtNetwork.QNetworkRequest(QtCore.QUrl(toUrl))
            request.setHeader(QtNetwork.QNetworkRequest.ContentTypeHeader, "application/json; charset=UTF-8")

            self.nam2.post(request, document.toJson())
        except Exception as e:
            print(e)

    def adjustBrightness(self):
        self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': self.ui.Brightnessslider.value()})

Kent-Dorfman

[removed unnecessary phrasing that was not directly related to the problem at hand - @AndyS]

instead of passing each change value during the drag, only do the post on the final slider value after done sliding.

SGaist

Hi,

Did you check the network speed ?
The device reactivity ? It might not really appreciate getting so many connections per second. Depending on what it is, it might even be seen as a DOS attack.

Side note:
@Kris-Revi said in QJsondocument slowness when hooked up to a QSlider:

cfg = self.nam2.activeConfiguration()
cfg.setConnectTimeout(1000)

Why are you doing this for all calls ? You were already explained that it should be done once as it will apply to all connections made using that configuration.

Kris Revi

@Kent-Dorfman well yea, when "requests" and "httplib2" can do it i thought why can't Qt do it!

by using this:

url_json = self.boardURL + "/selectPattern"
headers = {"Content-Type": "application/json; charset=UTF-8"}
data = {"selectedPattern": self.selectedPattern}
response, content = http.request(url_json, "POST", headers=headers, body=json.dumps(data))

i get instant respons from the arduino! the only thing is i get a slight "lagg" on the slider itself! So that's why i thought i could give QNetwork and QJsonDocument a try!

@SGaist as mentioned above using "requests" and "httplib2" i get instant response no delay or "slowness" (with the little downside of the slider lagging sometimes)
yea about the connectionTimeout that is not supposed to be there stupid me just tryed to test it! (removed now)

Christian Ehrlicher

@Kris-Revi said in QJsondocument slowness when hooked up to a QSlider:

i get instant response no delay or "slowness"

How do you measure? Moving a slider generates a lot of events...

Kris Revi

@Christian-Ehrlicher i measure by looking at the LED's how fast they go bright when i slide the slider using the 2 methods

this is using QNetwork & QJsonDocument (Notice how slow and long it takes for the LED's to go full brightness and then off again)
https://vimeo.com/400919786

and here i am using requests and httplib2 (notice that when moving the slider it goes instantly! no delay or "slowness")
https://vimeo.com/400920348

jsulm

@Kris-Revi When using QNetwork & QJsonDocument I don not see ANY changes on your LEDs, so my guess is that your code with QNetwork & QJsonDocument is not working properly.

Kris Revi

@jsulm whaat? maybe it was hard to see on the video but you could see it, it's there!

QNetwork & QJsonDocument
Moves the slider from 0 to 255
Send 1 -> Wait -> No Error
Send 2 -> Wait -> No Error
Send 3 -> Wait -> No Error
Send 4 -> Wait -> No Error
Send 5 -> Wait -> No Error
and so on

it sends the data 1 at a time and then waiting for something and then it sends another one and waits and so on...

Using requests and httplib2
Moves the slider from 0 to 255
Send 1
Send 2
Send 3
Send 4
Send 5

here it just smacks it in with no waiting time

jsulm

@Kris-Revi OK, watched once more - yes, there is one change at the end of the video. It should work with QNetwork & QJsonDocument.
Can you post your current code?

Kris Revi

@jsulm

class software(QtWidgets.QMainWindow):
    def __init__(self, parent=None):
        QtWidgets.QWidget.__init__(self, parent)
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)
        self.ui.Brightnessslider.valueChanged.connect(self.adjustBrightness)

        self.nam = QtNetwork.QNetworkAccessManager()

    def doPost(self, toUrl, tojson):
        try:
            print(tojson)
            document = QJsonDocument(tojson)

            request = QtNetwork.QNetworkRequest(QtCore.QUrl(toUrl))
            request.setHeader(QtNetwork.QNetworkRequest.ContentTypeHeader, "application/json; charset=UTF-8")

            self.nam.post(request, document.toJson())
        except Exception as e:
            print(e)

    def adjustBrightness(self):
        self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': self.ui.Brightnessslider.value()})

SGaist

One thing comes to mind: QNAM handles up to 6 requests in parallel and then queues the other ones to be execute as soon as possible. requests as well as httplib2 do not have that kind of consideration as they are not asynchronous therefore I think that what you might be observing might be related to architectural differences.

Kris Revi

@SGaist and sadly there is nothing i can do there? :/ nothing i can turn off or adjust?

mrjj

@Kris-Revi
Hi
As far as i know, you cannot alter the limit of 6.

Christian Ehrlicher

I'm pretty sure that's not a problem of QNAM but somewhere else. Maybe the device does not answer fast enough or so so that QNAM is waiting for the response very long.

Kris Revi

@Christian-Ehrlicher sadly it is QNAM! when using "requests", "httplib2" or "urllib3" it is INSTANT response! no queue or waiting!

mrjj

@Kris-Revi
And the other end uses the same parsing and reaction code regards less of you using
httplib2 or NAM ?
So the only difference is the sending?

Kris Revi

@mrjj exactly!

mrjj

@Kris-Revi
Well its very likely SGaist is right and what you see is related to architectural differences.
NAM is async so pr request it will have a slight delay before actually sending compared to
a lib which is blocking and sends at once.
That said its normally very fast and even the slider will generate heaps of
signals, it should fast catch up if parsing is fast enough.

If you limit your sending to 6 outstanding, does it then react almost as fast ?

i mean something like.
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 10})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 20})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 30})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 40})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 50})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 60})

Christian Ehrlicher

You must be something doing very wrong:

static int s_requestFinishedCount = 0;
static const int s_maxRequests = 100;

int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);
    QElapsedTimer timer;
    timer.start();
    QNetworkAccessManager nam;
    QNetworkRequest req(QUrl::fromUserInput("http://192.168.178.200/"));
    for (int i = 0; i < s_maxRequests; ++i)
    {
      QNetworkReply *reply = nam.get(req);
      QObject::connect(reply, &QNetworkReply::finished,
                       reply, []()
      {
        qDebug() << "s_requestFinishedCount:" << s_requestFinishedCount;
        if (++s_requestFinishedCount == s_maxRequests)
          QCoreApplication::quit();
      });
      QObject::connect(reply, &QNetworkReply::finished,
                       reply, &QNetworkReply::deleteLater);
    }
    int ret =app.exec();
    qDebug() << "Elapsed:" << timer.elapsed() << ", ret: " << ret;

    return ret;
}

--> 580ms

shell:

date
for start in {1..100};
do
  wget -nv http://192.168.178.200 2>&1 > /dev/null
done
date

--> 11 seconds

The ip is a raspi 1 delivering a very small website

Kris Revi

@mrjj sadly it looks like if i can't controll / adjust / remove the queue system from QNAM im stuck using either "requests", "httplib2" or "urllib3" as they are instant :/ i can't have that queue system it takes ages befor the brightness levels of the LED's are where the slider is set to :/

kshegunov

@Kris-Revi said in QJsondocument slowness when hooked up to a QSlider:

@mrjj sadly it looks like if i can't controll / adjust / remove the queue system from QNAM im stuck using either "requests", "httplib2" or "urllib3" as they are instant :/ i can't have that queue system it takes ages befor the brightness levels of the LED's are where the slider is set to :/

I'm pretty sure with QNAM you're flooding the device sending near 10 times the payload (i.e. you're DoS-ing your device). What you can and should do instead is to disentangle the slider from the communication and buffer the slider's events instead of flushing them directly through the network. That is you introduce a timer that ticks every 200ms or so (which is below the typical reaction time of a human anyway), and send a message to the device if the slider's value has changed in the meantime. In Qt this'd look something like this:

QObject::connect(slider, &QAbstractSlider::valueChanged, controller, &ControllerClass::setValue);
QObject::connect(timer, &QTimer::timeout, controller, &ControllerClass::sendNetworkData);

where all the slots and signals do the obvious - the ControllerClass::setValue just saves the new value and if it's different from the previous raises an internal dirty state. ControllerClass::sendNetworkData checks if the state is dirty, and if so, sends the new data and resets the flag.

Qt World Summit: Submit your Presentation

QJsondocument slowness when hooked up to a QSlider