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 <[email protected]>
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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
