|
From: Jérôme L. <lod...@us...> - 2014-02-27 06:46:50
|
Le mardi 25 février 2014 23:39:38 Daniel J Sebald a écrit : > > So could you point out a specific past or present problem in the Qt > > terminal that is due to the fact that no event loop is running in the > > inboard driver ? > > The answer is "no". But the follow up to that is I really didn't search > for that. I'm trying to solve the problem of the Qt terminal apparently > not working on Mac OSX or Windows the way it should in combination with > the fact that I don't have Mac OSX or Windows. So I'm striving for an > event loop in hopes that makes the setup work better on all platforms. I > can't answer your question...that is, without looking into greater > detail of the Qt source code. Maybe I am wrong, but I think that adding an event loop will not make things work better. All the difficulties we had to make the Qt terminal work on all platforms are related to correctly setting the size of the plot window and correctly integrating the initialization of the QLocalSocket into the workflow of the main gnuplot program; which are problems that you will also face with an event loop. If you are motivated to pursue your idea, we will be able to balance whether things are less quirky or not with an event loop, but as Ethan said, things are already working almost correctly. > > motivation for this was a significant performance increase: the > > initialization of a QApplication requires more than 0.5 s against a few > > 10ms for a QCoreApplication. Moving back the font metric business in the > > main gnuplot program will require to instantiate again a QApplication > > and thus cancel this performance improvement. > > The 0.5 s happened every time a new Qt window is opened? No, only for the first one. But my motivation for this patch was that I have developed a monitoring application that fires about 20 gnuplot instances that forward their plots to a single Qt application (much like the embed_example, but with a gnuplot process dedicated tor each plot). With qt_term.cpp using a QApplication, my application took more than 10s to start up. > So, how about as a first step this weekend I take just the QProcess > startup code and make a nice diff/patch for you to try out and tweak how > you see fit. Let's see ! Jérôme |