[patch] redraw optimization now including tables
Hello, below is an improved version of the redraw optimization. It now also covers table based pages - at least to some point. The challenge is to make the already commited optimization work recursively. Other than I originally thought topLevel is always a Textblock. Table based pages simply consist of a Textblock with a huge Table as child widget. Textblock now needs to avoid redrawing the child area when the table size increases. The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find. Regards, Johannes
Hi Johannes, On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote:
Hello,
below is an improved version of the redraw optimization. It now also covers table based pages - at least to some point.
Yes, in fact it avoids redraws on the test posted in my last email. If I give that test another page, e.g. www.gnu-darwin.org/update.html, it can also avoid _some_ redraws. So the partial optimization seems to be working.
The challenge is to make the already commited optimization work recursively.
Do you want me to commit this new patch, or to keep the already committed one?
Other than I originally thought topLevel is always a Textblock. Table based pages simply consist of a Textblock with a huge Table as child widget. Textblock now needs to avoid redrawing the child area when the table size increases.
AFAIU textblock draws by lines and as the first line is a huge table it requests a redraw of it. I don't know yet why textblock is requesting a redraw; I assume that as the table size changed, textblock gets notified and as it doesn't know better it asks the child widgets for a full redraw. From a distance it looks like a conditionalRedraw() may be the needed call (I don't know well what expose means). I mean if this conditional redraw sees that nothing has changed in the specified area, it can simply return, otherwise redraw.
The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find.
I haven't found any anomalies. :-) -- Cheers Jorge.-
Hi Jorge, On Fri, Feb 29, 2008 at 10:18:45AM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Wed, Feb 27, 2008 at 05:56:36PM +0100, Johannes Hofmann wrote:
Hello,
below is an improved version of the redraw optimization. It now also covers table based pages - at least to some point.
Yes, in fact it avoids redraws on the test posted in my last email. If I give that test another page, e.g. www.gnu-darwin.org/update.html, it can also avoid _some_ redraws. So the partial optimization seems to be working.
Yes, the patch only tries to avoid redraws that change nothing on the screen. For complex tables that get rearranged all the time while loading, there is still a lot of redraws. However there is certainly room for improvement. For the fun of it, you can comment out the lines in table.hh where redrawY gets reset. That saves a lot of redraws at the cost of some anomalies...
The challenge is to make the already commited optimization work recursively.
Do you want me to commit this new patch, or to keep the already committed one?
Other than I originally thought topLevel is always a Textblock. Table based pages simply consist of a Textblock with a huge Table as child widget. Textblock now needs to avoid redrawing the child area when the table size increases.
AFAIU textblock draws by lines and as the first line is a huge table it requests a redraw of it.
With this patch it does not. It leaves the drawing of the table to the table code.
I don't know yet why textblock is requesting a redraw; I assume that as the table size changed, textblock gets notified and as it doesn't know better it asks the child widgets for a full redraw.
If the resizing does not change anything that is actually drawn by the Textblock (like real text), it does not need to request a redraw.
From a distance it looks like a conditionalRedraw() may be the needed call (I don't know well what expose means). I mean if this conditional redraw sees that nothing has changed in the specified area, it can simply return, otherwise redraw.
Yes, that's the idea of the new virtual method resizeDrawImpl(). Each widget can remember what has already been drawn and what might have changed because of resizes and then draw only the necessary parts. It depends on each widget how careful it is. Tables have the unfortunate property of changing their layout all over when new cells are added thereby requiring complete redraws.
The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find.
I haven't found any anomalies. :-)
Excellent. Then please commit this one. I will try to improve upon this. Cheers, Johannes
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hi,
[...] From a distance it looks like a conditionalRedraw() may be the needed call (I don't know well what expose means). I mean if this conditional redraw sees that nothing has changed in the specified area, it can simply return, otherwise redraw.
Yes, that's the idea of the new virtual method resizeDrawImpl(). Each widget can remember what has already been drawn and what might have changed because of resizes and then draw only the necessary parts. It depends on each widget how careful it is. Tables have the unfortunate property of changing their layout all over when new cells are added thereby requiring complete redraws.
We may track the colWidths vector. If it doesn't change, layout is kept.
The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find.
I haven't found any anomalies. :-)
Excellent. Then please commit this one. I will try to improve upon this.
Patch committed. Thanks for the explanations. I'll give it some testing when having some time. -- Cheers Jorge.-
participants (2)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de