Ideal D GUI Toolkit

Diggory diggsey at googlemail.com
Mon May 20 23:23:58 PDT 2013


> See my DConf talk in a few days (I was #3 on Day 2). It has a 
> pattern for concurrent data mutation at the end that might be 
> more useful than a global lock, which has some pretty 
> disturbing implications for high-performance rendering code.

I can't help but feel that making them concurrent is going to 
provide very marginal benefits. Rendering code is already 
essentially concurrent since you don't usually block until the 
GPU is done rendering, you just tell it what to do and let it get 
on with it.

Also, there's no point doing multiple renders per UI update 
because you'll just be drawing the same thing, and no point doing 
multiple UI updates per render because in the end only the most 
recent update will be shown. Anything other than sequentially 
executing "render -> update -> render -> update" is redundant.

To me it makes more sense to do all the updating and rendering in 
a background thread with a thin layer over the top to hide the 
details of synchronising with this background thread from the 
programmer.


More information about the Digitalmars-d mailing list