Attempting to use x11perf to measure performance revealed a fairly serious weakness in the dfps code in that use case. In between fps ticks, the updated_region would grow to have thousands of rectangles, which made processing extraordinarily slow. This patch provides a cap on the number of rectangles inside a region; once it reaches the cap, we collapse the update_region to just transmit the bounding rectangle instead. Signed-off-by: Jeremy White <jwhite@xxxxxxxxxxxxxxx> --- src/dfps.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/dfps.c b/src/dfps.c index a57523b..5db34dc 100644 --- a/src/dfps.c +++ b/src/dfps.c @@ -128,12 +128,29 @@ static Bool unaccel (void) return FALSE; } + +/* Establish a maximum number of disparate regions we'll track before we just + treat the entire bounding rectangle as having changed. + + The number 20 seemed intuitive, and also produced the best results in + benchmarking x11perf -circle10 -repeat 1 +*/ +#define DFPS_MAX_UPDATE_REGIONS 20 +static void dfps_update_box(RegionPtr dest, int x_1, int x_2, int y_1, int y_2); + static void dfps_update_region(RegionPtr dest, RegionPtr src) { Bool throwaway_bool; RegionAppend(dest, src); RegionValidate(dest, &throwaway_bool); + if (RegionNumRects(dest) > DFPS_MAX_UPDATE_REGIONS) + { + struct pixman_box16 box = * (RegionExtents(dest)); + RegionUninit(dest); + RegionInit(dest, NULL, 0); + dfps_update_box(dest, box.x1, box.x2, box.y1, box.y2); + } } static void dfps_update_box(RegionPtr dest, int x_1, int x_2, int y_1, int y_2) -- 1.7.10.4 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel