Re: OT thoughts - was Re: [fltk.coredev] Fl_Choice initiates infinite loop

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
Previous Message ]New Message | Reply ]Next Message ]

Re: OT thoughts - was Re: Fl_Choice initiates infinite loop Ian MacArthur 05:17 Jun 21 top right image
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
To view this discussion on the web visit
Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.