Announcement

Collapse
No announcement yet.

30-bit Deep Color For GNOME On Wayland Will Likely Take Some Time

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by pal666 View Post
    i can assure you that multithreaded gui toolkits can't work. toolkit should be single threaded, but it should do only gui-related stuff, all heavy lifting(which is user code) should be submitted to other threads. so toolkit's single-threadedness in the right thing, application itself should be multithreaded
    I guess the biggest issue is, as the code base grows, at some point it becomes hard to guess when your application logic is "slow enough" to be offloaded to another thread. It might happen gradually. It's easy if you do I/O bound stuff, but if your slow code is CPU bound, you'll need a profiler. It's also somewhat vague - on modern machines, GUI toolkits typically offer lots of headroom for slow user code, yet they can only do some N amount of instructions per GUI frame. So they're real-time systems with huge amounts of extra CPU power. If one wanted a disciplined approach to GUI building, one would probably need some non Turing complete language where you can calculate the total number of steps some application logic code can take. That way the compiler could already tell at compile time if some application logic code is too slow to run on a system with some predefined specs.

    Other than that, having multiple threads doing the core GUI logic just complicates things and won't provide any extra functionality one can't have with just one thread + explicit allocation of new worker threads.
    Last edited by caligula; 23 August 2020, 12:01 PM.

    Comment

    Working...
    X