Re: In GTK, how are screen coordinates mapped to GUI objects?

[Paul Davis <paul linuxaudiosystems com>]

On Mon, May 11, 2015 at 5:30 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:

Computers are *fast*. It turns out that simply recursively walking
down all children is fast enough for most cases. It's a complicated
walk, but it's entirely doable. You can see the code for the walk
here:

https://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c#n7247

notice the assumption that there's no Z-axis ordering. this is important and simplifies the code/algorithm significantly. many modern applications occupy what we might call "2-1/2D", where the 3rd dimension doesn't represent real space, but the stacking of items does have some semantic significance.

the tree walking algorithm also causes issues with any situations (which admittedly are rare) where objects are highly non-rectangular.

 

More complex data structures, like a map of pixel to object, would
take up too much memory, or require too much effort to suitably parse.
The simple and brute force solution often works well, because you'll
never have more than 100 visible children in the worst case, and 100
is not a big enough number to optimize for.

this number isn't realistic in the more general case where the "things" on the screen are less heavy-weight than widgets. So certainly it works OK for the GDK/GTK case, but in terms of a general mapping, optimizations do and can matter. A typical somewhat complex session in Ardour that involves MIDI and audio data might have in excess of 2k objects on the screen, and in extreme cases, a factor of ten larger.

unfortunately, the map of pixel to object is also too expensive in that case. we don't have the right answer (yet), so we too walk the tree, but we have to take layering (z-axis) into account. it easy to see this slow down certain aspects of GUI performance.