>> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days > While true, the same shader

>> we have evidence we can do faster on the GPU with various shaders than any of us can do with hand written assembler these days > While true, the same shader can be written and incorporated in an engine written in C. This is not true, unless you do all the same plumbing. We have two major pieces of evidence for this: 1) gtk-theme-engines from 2.x days almost universally caused crashes in applications when the did stuff wrong (and they all did) 2) You can't hide the details of the GPU pipeline behind a theme. it really changes the entire model of the application, how you store and cache state, how you pass it to the GPU, when you deliver that information, etc. > The most important feature is API stability so that good themes can be created. This is exactly why we want to have a stable release that wont be getting breaking changes. We think, practically, that most application developers will target the stable release (and therefore the stable themes). We think the primary users of unstable will be GNOME applications or other desktops that choose to align themselves with the GTK unstable cycle. > For example, some Gtk2 scrollbar settings like the arrow buttons seem to be gone in Gtk3. Is the idea that scrollbars should be drawn and callbacks implemented in JavaScript for arrow buttons? I'm not totally up to date on context here, bugzilla would be the best place to discuss this further.