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

Michel Dänzer michel at daenzer.net
Wed Jan 19 09:51:58 PST 2011


On Mit, 2011-01-19 at 18:29 +0100, Maarten Maathuis wrote: 
> 2011/1/19 Michel Dänzer <michel at daenzer.net>:
> > 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.

I don't think it is. If latency is really the issue, the timeout period
approach seems most appropriate.


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


More information about the xorg-devel mailing list