Stefan Schimanski wrote:

Am 17.10.2007 um 20:07 schrieb Joost Verburg:

Andre Poenitz wrote:
On Wed, Oct 17, 2007 at 05:57:12PM +0200, Stefan Schimanski wrote:
The patch is simple: Open GuiPainter.cpp. At the top is a #define macro which can be set as you like to enable or disable the cache.
Could that be a command line option?

Why not a normal preference? The cache could be disabled by default but users with old computers can enable it for better performance with less font quality.

Some general questions about the whole pixmap cache approach:

1. How many pixmaps are cached?

All words or math symbols and characters. There is enough room for more than one page. In my experience, it's more like three or four pages. Of course this also means that when typing only the current word is effectively drawn; all other words are cached even when a full screen redraw is needed. This is where the speedup is really worth it.

2. I guess the main speedup happens when the screen is slowly scrolled, i.e. most of the content is the same as before, but just shifted a bit. Did anybody measure the speedup in this case?

The difference is simple: in one case _all_ words appearing on the screen are drawn, in the other case, only words appearing that are not already in the cache are drawn.

3. Is there any speedup or slowdown when scrolling fast, i.e. by dragging the scrollbar or pressing page up/down?

Not really.

I guess then many pixmaps are created and thrown away all the time.

Depends on the contents but reused words are not drawn again.

4. If only slow scrolling is made faster, wouldn't it be better and easier to cache paragraphs which are not changed (then we don't need the transparent pixmaps anymore and sub-pixel rendering is no problem anymore)?

This is a longer term solution that needs further redesign of our metrics and drawing architecture. I am not sure I'll have time to do achieve this in the 1.6 time frame... maybe 1.7.

5. ... or to directly shift the screen by bitblt'ing the backing pixmap up or down?

This one is feasible but needs some architectural changes too.

Abdel.

Reply via email to