Hi Jorge, On Thu, Feb 07, 2008 at 06:32:55PM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 07, 2008 at 09:50:00PM +0100, Johannes Hofmann wrote:
Hi,
On Thu, Feb 07, 2008 at 05:23:40PM -0300, Jorge Arellano Cid wrote:
- snip -
If I understand this correctly, the patch now is equivalent to removing the calls to queueDrawTotal(), where asap == false, right?
Right.
But the idea is to queue when asap == false, and to set a delayed draw that is user adjustable in seconds (e.g. 0, 0.5, 1, 3, ...).
Ok. I think we mostly agree on what needs to be done. My only concern with your aproach is that I wonder why the new asap parameter is needed: When to call with asap == true and when to call it with asap == false?
As a synonym for flush.
Ok, but how do you know at widget level whether a flush is good or whether it's better to queue the redraw?
For instance when and image finishes loading we can call with asap=true and if we want it to display incrementally, we can asap=true every update.
This is a great example. Think about an html image gallery. A partial update of the main image is much more important and should be rendered immediately than a 1x1 pixel spacer that had been loaded completely. My point is, that we can't decide at widget level whether the redraw should be done now or later.
asap=false can mean: "this operation is needed but can be delayed".
* Frequent redraws are good if they update the visible content. E.g. when loading a page over a slow line. Immediate feedback to the user is a great feature of dillo. The screen flickering can be avoided with some double buffer mechanism.
Choosing refresh_delay=0 would give immediate feedback.
refresh_delay=3 could yield low CPU usage and very good performance.
Yes, that's exactly what my patch does. It delays the actual drawing operation if there is other things to do (e.g. new data is coming in).
Yes, both patches attack the same problem after all.
Once the code is cleaned, we can choose the one that fits better. I liked the flush/asap approach because it was putting unnecesary calls under the spotlight.
Yes I also commented out redraw() operations in various places for testing, but it's really difficult to find places where they are completely unnecessary.
It was also faster in some tests. Although this may change after the cleanup.
[...] * It would be nice, if we could decide whether a resizing widget affects the layout that is currently visible, so that we could avoid redrawing in this case. This would avoid redrawing when loading very long pages as the DragonFly package list. But I don't think this is easy.
Back in 2005 we needed to test the prototype quickly, so it was reasonable to simply add, for instance, a queuedrawTotal() call when only a queuedraw() was needed and to postpone clipping until the basics were working.
I believe this is what is asking for a review now.
Yes sure. There might be places where we can replace the queueDrawTotal(). Let's go through the code with this in mind.
OK.
I also have yet to understand how it all fits together... (allocate/resize/draw)
Also we should agree on what we actually want to optimize. I don't think CPU usage or number of redraws are enough. Instead dillo should be usable and "feel fast" on fast and slow or loaded systems (if CPU is available, why not use it?).
I believe we can have it all! (as explained above).
Same here :-)
Good.
Cheers, Johannes