[PATCH 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.

[Michel Dänzer]

On Mit, 2011-01-19 at 10:09 +0100, Maarten Maathuis wrote: 
> This is it, 10 ms a short time and even with this value large amounts
> of text are still not shown fluently (the impression that some pieces
> are never drawn). This is on top of the previous 3 patches.
> 
> diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
> index 4f49905..c0c730d 100644
> --- a/exa/exa_migration_mixed.c
> +++ b/exa/exa_migration_mixed.c
> @@ -150,12 +150,26 @@ exaDamageReport_mixed(DamagePtr pDamage,
> RegionPtr pRegion, void *closure)
>      if (!pExaPixmap->use_gpu_copy && exaPixmapHasGpuCopy(pPixmap)) {
>  	ExaScreenPriv(pPixmap->drawable.pScreen);
> 
> -	/* Front buffer: Don't wait for the block handler to copy back the data.
> -	 * This avoids annoying latency if you encounter a lot of software rendering.
> +	/* Front buffer: Don't wait for the block handler to copy back the
> data, unless
> +	 * it has been moved back in the last 10 ms. This avoid annoying latency when
> +	 * troughput is low, but keeps troughput acceptable at higher levels.
>  	 */
> -	if (pPixmap == pScreen->GetScreenPixmap(pScreen))
> -		exaMoveInPixmap_mixed(pPixmap);
> -	else {
> +	if (pPixmap == pScreen->GetScreenPixmap(pScreen)) {
> +		CARD32 now = GetTimeInMillis();
> +		if ((now - pExaScr->last_time_front_mixed_pixmap) > 10) {
> +			pExaScr->last_time_front_mixed_pixmap = now;
> +			exaMoveInPixmap_mixed(pPixmap);
> +
> +			if (pExaScr->deferred_mixed_pixmap == pPixmap)
> +				pExaScr->deferred_mixed_pixmap = NULL;
> +		} else {
> +			if (pExaScr->deferred_mixed_pixmap &&
> +			    pExaScr->deferred_mixed_pixmap != pPixmap)
> +			    exaMoveInPixmap_mixed(pExaScr->deferred_mixed_pixmap);
> +
> +			pExaScr->deferred_mixed_pixmap = pPixmap;
> +		}
> +	} else {
>  		if (pExaScr->deferred_mixed_pixmap &&
>  		    pExaScr->deferred_mixed_pixmap != pPixmap)
>  		    exaMoveInPixmap_mixed(pExaScr->deferred_mixed_pixmap);

I still can't help wondering if we aren't missing something about what
makes the difference between the text being 'shown' or not[0], but this
approach would be getting rather complicated already, and if there's no
timeout period which gives a better tradeoff between latency and
throughput, I guess erring on the side of the former is better for now.
So, feel free to add my

Reviewed-by: Michel Dänzer <michel at daenzer.net>

to your patch 3/3, and thanks for taking the time to get more
information.


[0] E.g., maybe the larger number of UploadToScreen operations results
in the driver flushing commands to the GPU more often?

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer