I'm reliably informed that sysprof doesn't work well on x86_64 platforms, whcih explains the not-so-good profiles I'm getting. (The crash / video corruption, I've no idea).
I'm also informed that the problem we're seeing is probably GDK's fault for keeing the invalidated region as a GdkRegion which requires some maths to compute the union of the existing damage region and our new region each time we invalidate something.
(17:21:48) pcjc2: Am trying to chase why lots of small invalidates in GDK adds up to a huge slow-down
(17:23:06) pcjc2: seems that for our workload it may be cheaper just to compute our own invalidate region and just consider the bounding rectangle of all redraws requested, not let GDK compute some complex shape
(17:23:48) ickle: actually, track the invalidate rectangles as an array, then compute the union at redraw
(17:24:07) ***pcjc2 wonders why this isn't exactly what GDK is doing...
(17:24:21) ickle: it keeps it as a GdkRegion
(17:24:32) ickle: XY banded at all times
(17:24:52) ***ickle has a whole layer on top of damage to avoid computing regions too soon
(17:25:12) pcjc2: XY banded is the way GdkRegion computes the shape?
(17:25:27) pcjc2: lots of little rectangles which add up to the whole invalidated shape?
(17:25:29) ickle: yes, and that is an invariant property of the region
(17:25:57) ickle: so every time you invalidate a dirty rectangle, that rectangle is unioned with the existing invalidate region
(17:26:09) pcjc2: It is sad GDK / GTK don't just "get this right" for us - I can't see why writing an app-space replacement should ever be faster
(17:26:24) ickle: O(nn) instead of )(n ln n)
(17:26:57) pcjc2: The API looks right... but does something stupid - so the "correct" / "better" fix is to fix GDK to be more optimal when computing invalidated regions
(17:27:06) pcjc2: or does it all come through the X server?
(17:27:18) ickle: GDK here
(17:27:38) ickle: I have a similar issue inside the DDX though
(17:27:49) pcjc2: sadly, we'll probably have to fix it in the app, since we support ancient GTK versions
I'm reliably informed that sysprof doesn't work well on x86_64 platforms, whcih explains the not-so-good profiles I'm getting. (The crash / video corruption, I've no idea).
I'm also informed that the problem we're seeing is probably GDK's fault for keeing the invalidated region as a GdkRegion which requires some maths to compute the union of the existing damage region and our new region each time we invalidate something.
(17:21:48) pcjc2: Am trying to chase why lots of small invalidates in GDK adds up to a huge slow-down
(17:23:06) pcjc2: seems that for our workload it may be cheaper just to compute our own invalidate region and just consider the bounding rectangle of all redraws requested, not let GDK compute some complex shape
(17:23:48) ickle: actually, track the invalidate rectangles as an array, then compute the union at redraw
(17:24:07) ***pcjc2 wonders why this isn't exactly what GDK is doing...
(17:24:21) ickle: it keeps it as a GdkRegion
(17:24:32) ickle: XY banded at all times
(17:24:52) ***ickle has a whole layer on top of damage to avoid computing regions too soon
(17:25:12) pcjc2: XY banded is the way GdkRegion computes the shape?
(17:25:27) pcjc2: lots of little rectangles which add up to the whole invalidated shape?
(17:25:29) ickle: yes, and that is an invariant property of the region
(17:25:57) ickle: so every time you invalidate a dirty rectangle, that rectangle is unioned with the existing invalidate region
(17:26:09) pcjc2: It is sad GDK / GTK don't just "get this right" for us - I can't see why writing an app-space replacement should ever be faster
(17:26:24) ickle: O(nn) instead of )(n ln n)
(17:26:57) pcjc2: The API looks right... but does something stupid - so the "correct" / "better" fix is to fix GDK to be more optimal when computing invalidated regions
(17:27:06) pcjc2: or does it all come through the X server?
(17:27:18) ickle: GDK here
(17:27:38) ickle: I have a similar issue inside the DDX though
(17:27:49) pcjc2: sadly, we'll probably have to fix it in the app, since we support ancient GTK versions