Make prefetch work at the tile level, not page level

[Martin Spacek]

If I understand correctly, prefetch should eventually be optimized for tiles instead of pages. Just a reminder.

[Adam Reichold (adamreichold)]

PageItem::startRender should probably return the number of tiles and hence render tasks it has requested to start rendering so that DocumentView::on_prefetch_timeout can accomodate for this being larger than one in its prefetching budget.

[Adam Reichold (adamreichold)]

Adjust prefetching in trunk revision 1582 to allow prefetching of as many tiles as we would prefetch pages without tiling enabled. (With forward prefetching being issued before any backward prefetching if it is constrained by the tile budget.)

Maybe the one-tile-one-page ratio should be enlarged a bit, e.g. allowing to request rendering of twice as many tiles as pages? Unity however seems to work as intended.

[Martin Spacek (mspacek)]

I don't really understand what you did, but it seems to work! With tiling and prefetch enabled and prefetch set to 2, scrolling around at a reasonably slow rate pretty much eliminates the rendering placeholders. Great!

It's not clear to me what the prefetch limit represents when tiling is enabled. Is it the number of tiles to prefetch, or the number of pages, for which an approximate number of tiles spanning those pages will be prefetched instead? Though more complicated, the latter would probably be preferred. That way, the prefetch limit always refers to the (approximate) number of pages to prefetch.

Which reminds me, is it possible to add tooltips to some of the settings, to give a more detailed description of what they do?

[Adam Reichold (adamreichold)]

Hello,

Am 18.06.2014 01:22, schrieb Martin Spacek:
> I don't really understand what you did, but it seems to work! With
> tiling and prefetch enabled and prefetch set to 2, scrolling around at a
> reasonably slow rate pretty much eliminates the rendering placeholders.
> Great!
>
> It's not clear to me what the prefetch limit represents when tiling is
> enabled. Is it the number of tiles to prefetch, or the number of pages,
> for which an approximate number of tiles spanning those pages will be
> prefetched instead? Though more complicated, the latter would probably
> be preferred. That way, the prefetch limit always refers to the
> (approximate) number of pages to prefetch.

Currently it's pretty simple: "maxCost" is the number of page that would
be prefetched without tiling. "cost" is incremented by one for each tile
that started rendering (i.e. was not already in the cache.)

This means that if each page consists of two tiles, we will only
prefetch half the number of pages as without tiling. (Skewed into the
forward direction.) I chose this strategy since IMHO it is not useful to
prefetch a single tile of all pages within the usual prefetch range, but
that we should rather fetch as many tiles as possible of the closest pages.

Possible improvement: We could restart the prefetch timer if we
exhausted the budget before covering the whole range, that we will
eventually cover the usual amount of pages but still not flood the
thread pool?

In any case, I think the cost/budget interface between DocumentView and
TileItem via PageItem will allow us to tune this further without
DocumentView knowing anything about tiling, i.e. we can tune how
PageItem and TileItem determine the cost and how DocumentView
distributes its budget independently.

> Which reminds me, is it possible to add tooltips to some of the
> settings, to give a more detailed description of what they do?
>

Yes this is certainly possible. Very few settings already have a tool
tip that indicates that they are effective only after restart. One issue
with just adding any number of tool tips is that we currently describe
all settings in the online help and duplicating this might be a bit of a
maintenance (and translation) workload problem.

Best regards, Adam.