2011/1/19 Michel Dänzer <[email protected]>: > 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
One experiment would be to do a exaMoveInPixmap_mixed when (let's say) 10% of the screen becomes dirty, but this is even more complicated. But I'm willing to try if you think it's a good idea. > > 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 > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
