Hi, On Fri, Nov 09, 2007 at 08:59:22PM +0100, Johannes Hofmann wrote:

Hi Jorge,

On Wed, Nov 07, 2007 at 06:56:22PM -0300, Jorge Arellano Cid wrote:

...

Hi Johannes,

On Wed, Nov 07, 2007 at 09:46:25PM +0100, Johannes Hofmann wrote:

*snip*

...

...

The last point is more difficult to improve. For example think of a long page containing just text. Every time a new chunk comes in over the net, dillo creates a redraw request for the whole screen, even though there is already enough text to fill the screen so that the new data does not actually change the layout of the part that is currently visible.

But how can we know, whether new data changes the layout of the currently visible part or not?

Please excuse me if I'm naive on this subject (it's not my main area of expertise).

I think that if the visible widgets don't change their size, and the just-added widgets are out of sight, we can delay the redraw (maybe setting a damage flag or whatever it is that works on the out-of-sight widgets), and not request a full redraw.

I think we would not even need to mark them. They get redrawn anyway when they come back in sight.

Great.

I see one problem however. Many pages just consist of one large textblock. And part of this textblock is obviously visible while loading the page. But with every chunk of data from the net the size of this textblock will change and we would redraw it, even though the part of it that is visible did not change. I think we need a solution for this common case.

Yes, it's true.

I already thought about checking whether something changed at a word by word level, but this feels a bit like overkill.

But it could work. Let's say we keep the convas coordinate of the last line in a textblock in a state variable of the object instance. If that line is out of sight we can leave: mustQueueResize = false and be more careful about calling Textblock::flush().

...

If that approach is too complex to implement, then maybe it's not worth the effort.

What do you think?

Maybe. The actual redraws are done when fltk is idle otherwise. So many redraw request are collapsed into one already.

However redraws are much more expensive with antialiased text than they were in dillo1, so we should at least try to reduce them.

I agree, and it looks like the right thing to do.

...

...

The only rather simple improvement I can think of is that we could use the image sizes provided in the <img/> tags and only issue a Layout::queueResize() if the image proves to be of a different size. Currently there is a Layout::queueResize() for every image as it gets loaded.

A simple way to throttle redraws is to make it in the html parser, and parse at let's say at 3 seconds intervals and at EOF. I've done that before on prototypes.

Yes, but I actually like dillos behaviour to show incoming content immediately in contrast to firefox and friends.

Me too. ;) -- Cheers Jorge.-