Re: [dev] [st] Drawing optimizations

From: pancake <pancake_AT_youterm.com>
Date: Fri, 21 Oct 2011 00:18:27 +0200

I would like to see similar optimizations in libdraw and swk.

Another optimization would be to add a dirty for columns.. Or well.. For rectangles which are the damaged areas. This will require some more work in order to get a list a smallest rectangles to be redrawn. We have to find a balance between number of rectangles and rectangle sizes.

I think that most of times redrawn areas are in blocks and use to happen in a single area. So an array of 8 rectangles would be more than enought.

We need an api that we can share with other projects that group those damaged areas into rrctangle groups so at the end the redrawn iteration gets faster.

Full screen redrae would be a single rectangle and 3 lines update will be that too. Fot dvtm and so on.. The redrawn area can be just the window that changes its contents and when we type text only the new char is going to be updated.

Swk needs the same optimization as long as all widgets are redrawn everytime.

Another optimization would be to store pixmaps for blocks and allow to move them along the buffer. This will allow faster redrawn for scrolling and long listings.

iOS uses opengl pixmaps of 1024x1024 for the browser, pdf, lists, etc.. So widgets dont need to be rewrotten and texts inside them doesnt need to be redrawn into the buffer again because they didnt changed.

We can think at some point to use those algorithms for swk too. That will benefit the performance a lot.

On 21/10/2011, at 0:00, Aurélien Aptel <aurelien.aptel_AT_gmail.com> wrote:

> Hi,
>
> I know st rendering is slow. I'm currently trying out different
> solutions but I can tell you profiling X calls is no fun.
>
> tip now uses a simple dirty flag per line algorithm.
> Each modified line has the flag set to 1. Only dirty lines are drawn
> and once it's done their flag is set back to 0.
> I've noticed a significant speed up. I'll try more ideas in the near future.
>
Received on Fri Oct 21 2011 - 00:18:27 CEST

This archive was generated by hypermail 2.3.0 : Fri Oct 21 2011 - 00:24:03 CEST