|
|
On 21 Jun 2022, at 04:12, Rob McDonald wrote:
>
> There are admittedly a lot of things that can be done to make my program faster in places -- lots of them are easier than making it thread safe. Unfortunately, while there is sometimes funding to add features, there is seldom funding to buy down technical debt.
This: I know...
>
> I also struggle a bit with what a multi-threaded use case would be like. In my program, you are interacting with a central model. When you make a change, it takes a certain amount of time. It doesn't really make sense to start making the next change before the model has updated for the previous one -- you're somewhat forced to serialize around the user's ability to see the impact of their change.
Well.... I’d say you need to serialize their (ability to make) changes to the model, but that does not necessarily mean you need to lock out the UI whilst the model is recalculated.
Running the computation in the context of the callback does tend to lock out the UI, which just seems wrong to me (and on some platforms can lead to weirdness if the OS is sending events that seem to be ignored...)
So I’d always favour returning the callback ASAP and keeping the UI “alive” and responsive - even if the response is just to say “hold on, I’m still busy!"
>
> Think about applying a filter or blur in Photoshop or Gimp. If it takes 1.5 seconds for the filter to be applied to your image -- does it make sense for the user to be already applying the next filter? In many ways, the best thing to do is show the user an hourglass (or spinning beachball) and make them wait.
Sure, but I’d counter with: “Ah ha! But applying a filter is a classic case where threading can help.” Since many of those operations do lend themselves to being accelerated by subdivision of the work... (Not that long ago I was using - I think it was the gimp - on a really slow old laptop, and I could actually see it filling in tiles ”randomly” across the scene as it applied the filter..)
And yes, I recognise you didn’t specifically mean an operation that lends itself to SIMD operations and to being split over multiple tiles.
The point is rather that you need to complete one change before you start the next; but the time it takes to complete the change can very often be shortened by subdividing the work; even where the subdivision itself adds a fair bit of extra work, it is often a net win. If it makes the job 50% harder but allows 400% more CPU to be brought to bear...
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/79D138B9-F1E9-4F63-9CD1-D0D2F8A2196F%40gmail.com.
[ Direct Link to Message ] | |
|
| |