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

[Maarten Maathuis]

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.

>
> 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
>



-- 
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.