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