On 11/03/12 19:58, Thiago Macieira wrote: > On domingo, 11 de março de 2012 19.39.31, Nikos Chantziaras wrote: >> The application is an engine for running >> programs in it, and those programs have their own internal event loops. >> They call callbacks so the host application can advance its own event >> loop. In those callbacks I then do processEvents(). There's no way >> around that. > > Yes, there is. You can use threads or you can use a custom event dispatcher. > And this is assuming that you tried but was unable to integrate the loops by > way of timer and socket notifier callbacks. Your choice should be: > > 1) if the library provides you with callbacks for when it updates timers and > socket notifiers, use the standard Qt event loop > > 2) if the library does not provide that, but allows you to add sockets > notifiers and timers, then you should write your own Qt event dispatcher > (inheriting from QAbstractEventDispatcher) and register the Qt sources with > that lib. > > 3) if the library does not provide either, you put its use in a thread > > Anything else is sub-optimal because you'll either wake up too often or you'll > delay event processing. Or, more likely, both, which is worse.
It provides neither. The callbacks are for doing graphics, audio and user input. So threading is the only option. I didn't go that route because you can't paint from a thread without using signals/slots, and that seemed rather inefficient compared to direct calls. But I guess I'll give it a try anyway. On modern hardware the overhead is probably not noticeable. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
