Skip to content
  • 0 Votes
    5 Posts
    387 Views
    E

    Just a quick update to tell you that I've been able to identify the widget that was causing trouble, installing a custom event listener on the QApplication, where I was logging all the events of type "Resize" as I had the impression that it was coming from there.

    I just wanted to share how I did that, in case someone else needs to investigate something similar in the future.

    Regarding the widget itself, I'm not very familiar with Qt widget's size policy strategy, but my incomplete understanding is that the size policy of a QTableView set to Minimum was somehow leading to an infinite loop of resize events (maybe when the resize of this widget was causing the resize of another widget ?). Changing the size policy seems to fix the issue.

    Thanks for everyone for the help!

  • 0 Votes
    9 Posts
    812 Views
    H

    @Pl45m4 Calling slots as a normal function directly from main thread, reading/writing from/to a variable of QObject (using mutex of course).

  • 0 Votes
    1 Posts
    611 Views
    No one has replied
  • 0 Votes
    2 Posts
    1k Views
    VRoninV

    @LRDPRDX said in In what thread would a QObject be deleted if it was moved to another QThread?:

    the dtor must be called and executed in the secondary thread not the main one. Am I right?

    Correct, that's what connect(thread, &QThread::finished, worker, &QObject::deleteLater); does and as you noted>

    No more events will be processed in the thread, except for deferred deletion events.

    Do the deleteLater will still picked up after the finished is emitted and the destructor will run in the secondary thread

  • 0 Votes
    4 Posts
    3k Views
    C

    @jsulm: Thank you for your reply. The part I missed is "The default implementation simply calls exec()."

    @J.Hilk: Thank you for the great set of examples. IMHO, this should be placed in the QThread Class Documentation.

  • 0 Votes
    2 Posts
    485 Views
    jsulmJ

    @texasRanger Why do you think you need an additional event loop? From your description I don't see any need for it. If file is changed you will get a signal from file watcher. You just need to make sure parsing of that file does not take too long.

  • 0 Votes
    3 Posts
    2k Views
    F

    @SGaist
    Thanks for answering.
    Basically, I am separating rendering and updating to have fixed-timestep updating (for physics etc) as well as as-fast-as-possible rendering with time interpolation. (Heavily heavily inspired from Gaffer on Games article)
    My code looks as follows (only slightly simplified):

    ... within my OpenGLContext void GLWindow::gameLoop() { const double delta = 1.0 / fixedUpdatesPerSecond; auto time = QDateTime::currentMSecsSinceEpoch(); double accumulated = 0.0; while (! this->terminate) { auto newTime = QDateTime::currentMSecsSinceEpoch(); double frameExecution = tdiff(time, newTime); time = newTime; accumulated += frameExecution; while (accumulated >= delta) { // Handle user input / system polling //However, since Qt has event driven polling, let's just call processEvents and then handle any input events by putting their results into a map. QCoreApplication::processEvents(); // Update our states this->updateState(delta); accumulated -= delta; } this->render(accumulated / delta); } }

    In the same class, I have updateState and render:

    void MyGL::updateState(float delta) { //... Bunch of commented-out code to make sure base loop works first if(myKeys.at(Qt::Key_W)) { cam->translateAlongForward(delta * 3.0); cam->update(); } } void MyGL::render(float aheadAlphaPercent) { this->update(); } void MyGL::paintGL() { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); lambertShader->setViewProj(cam->matrix()); // a lot of other drawing stuff }

    I know that my rendering code itself works because I initially tested it by just using a QTimer.

    Instead, I now do the following:

    ...in main... QApplication a(argc, argv); QSurfaceFormat::setDefaultFormat(format); MainWindow w; w.show(); w.start(); //return a.exec(); // ^Dont^want^to^uncomment^this^ ... MainWindow::start (MainWindow is QMainWindow subclass)... uiElements->glWindow->gameLoop(); //glWindow is subclass of OpenGLContext

    As you can see, I tried to avoid calling Qt's blocking event loop in QApplication::exec, but am still polling events. However, this doesn't work properly, as described in my first post.

  • 0 Votes
    4 Posts
    2k Views
    J.HilkJ

    Hi @Md0ngo said in QThread signals|calls to QChart are blocking the GUI:

    After so much time lost, solved it!!

    It seemed to be the fault of the default QSeries implementation... Series.append() apparently emit a couple of signals and resize the inner vector which contain the QPoints. This combined to a O(knĀ²) loop totally messes up the main event loop.

    It was "as easy" as refractoring the code so the thread builds up a QVector of QPoints, then signals each vector to the chart and it calls to series.replace() instead of append(), that is actually faster and lighter.

    great that you were able to fix it yourself, and I learned something new and important about QCharts thank you ;-)

    I was about to give up after trying the moveToThread way without success, but I was lucky enough to get the solution after finding this.

    So, not a matter of Qthreads after all.. Now I'm wondering whether refracting the code to create a dedicated event-loop was worth it or not.

    If an actual worker class is now replacing your infinite while loop, that you posted in the op, than yes it is, definitely!

    Don't forget to set your topic to solved ;-)

  • 0 Votes
    2 Posts
    434 Views
    SGaistS

    Hi,

    Maybe QAbstractEventDispatcher could be a starting point.

  • 0 Votes
    1 Posts
    315 Views
    No one has replied
  • 0 Votes
    4 Posts
    2k Views
    jsulmJ

    @robro You misunderstood what @VRonin wrote: you should NOT have such loops. Just use signals/slots in your app - there are no differences to UI apps.

  • 0 Votes
    11 Posts
    5k Views
    SGaistS

    And then you should maybe consider creating a widget to handle your threads requests for input one after the other or grouped. Whatever makes sense for your application.

  • 0 Votes
    6 Posts
    3k Views
    NorthsoftN

    @kshegunov thanks a lot!

  • Qt and GStreamer

    Unsolved General and Desktop
    2
    0 Votes
    2 Posts
    1k Views
    SGaistS

    Hi,

    Maybe the GStreamer QtGstreamer module might be of interest.

    Hope it helps

  • 0 Votes
    5 Posts
    2k Views
    kshegunovK

    @SGaist
    When I finish up my code the obvious run and if it crashes test will tell for sure.
    Unfortunately, the documentation is very cryptic of such issues ... :)

  • 0 Votes
    10 Posts
    10k Views
    mbruelM

    I'm having a new problem when I move a second QTcpSocket inside the thread.
    Everything seems to work fine but the thread is crashing (segmentation fault) after deletion (after receiving the destroyed signal). It seems to be an desallocation issue... I couldn't manage to figure out the problem yesterday and today...
    I'm going to write a easier example of my architecture and open a new post.
    Cheers

  • 0 Votes
    11 Posts
    6k Views
    M

    Yep,

    you can move as many objects you want in a single thread.

  • 0 Votes
    1 Posts
    676 Views
    No one has replied
  • 0 Votes
    10 Posts
    4k Views
    K

    I have found the problem. It was a blocking ftp download which did not finish because of broken communication. Pushing the download to a separate thread unveiled the problem respectively made it tracable.

  • 0 Votes
    1 Posts
    1k Views
    No one has replied