> 😊 that definitely does. > > Of course.... I wonder if you had removed that, but left in the QObject etc > etc, what would it have been. Likely, not much worse than 15ms.
Yep, once I removed the random generator object, I had the same thought: "could I go back to QObject?!?!", but as you mention, I don't think there's any reason for me to do that, unless I can think of a reason that I need to provide some sort of signal down at a tile level beyond just completion progress (since QFutureWatcher can handle the progress part). The only potential signal that comes to mind is between the tile::load() and tile::remap() steps I do need to know the min/max raw data values to compute what the remap parameters are. Currently I have to wait for the loadFutureWatcher to report it is finished, then I take a pass through every tile to calculate the global min/max values, then I can kick off the remap process with those parameters in hand. If the tile was an QObject and it emitted a signal to relay that information back then the global min/max is getting updated as each tile completes its first step, which means as soon as the last tile finishes, I'm good to go with the remap step instead of taking that pass through all the tiles to determine the global min/max. But I could also accomplish the same thing by modifying the loadTIle function that is passed to QtConcurrent to return a QPair<double, double> instead of returning void like it currently is Does. Then I would connect the future watcher's resultReadyAt(int index) signal to a slot in my tile manager that accomplishes the same thing, without making my tile class inherit from QObject. > > Why? IMO, Qt wouldn’t be what it is today, if simply allocating 60k QObjects > and connecting a signal to them too that long. > > But I think the overall architecture of what you have now, is MUCH better > and will scale to a more complex "actually do the work" system much better > than the other. I think I'm happy with it as a proof-of-concept design as I have it now - or at least once I replace the placeholder delays with the code that actually works on the data file. After that, I want to also implement the idea Konstantin suggested of just dividing the original image up into QThread::idealThreadCount() blocks and then compare the results on actual data and see which performs better. I'm guessing it'll be the latter since on my idealThreadCount() == 8 system, there's probably way less overhead in creating 8 things that do the work than 60,000+. Especially since the 60,000 items are still going to be funneled through 8 threads anyways. Sean _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
