Hi Johannes, Please excuse me for my scattered comments these days. I'm travelling visiting some relatives. On Mon, Feb 11, 2008 at 06:44:48AM +0100, Johannes Hofmann wrote:
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?
At widget level is not easy, and most probably can't be done in the general case. Asap is used as a way to solve these problems: With the patch that ignored redraws with asap=false, asap=true solved the problem of ensuring images were actually drawn sometime (fully updated). The same for main page: asap=true was requested when the network transfer was done, asserting that the main content was updated to the last bit. With the current patch, redraws with (asap==false) are not ignored but queued with a timeout (2 seconds); this ensures images and main pages are drawn. But in this case (asap==true) ensures you don't have to wait the timeout for fast pages. e.g. local files. This scheme allows for minimal CPU usage (big timeout) or fast updates (low or no timeout). If both can be accomplished from a central function without using the asap parameter; great.
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.
(as explained above). Now, with images, I beleive the main point is to eliminate uneccessary updates (i.e. flickering and wasted CPU time). For instance, I took place's large table (generated from C), and added an <img src='file:/tmp/ball.gif> to every form. That way I had a large page with lots of instances of the same image. Then got the page and image, served through a local cgi-program that can set the transfer speed. Test result: updates of out-of-screen images produced a full redraw. I believe this is the main source of unnecessary redraws. If the image is out-of-screen and it doesn't resize the parent widget, no full resize/redraw is needed. For instance, with the gallery example above, if the small image is updated and the table holding it is not forced a resize when not necessary, the update could be welcomed. Caveat Note: the current implemetation really implements ASAP. This is, the queue function calls redraw directly instead of queuing the redraw for the next idle call (which would be much better). Bottom line: Main problem: updates of out-of-screen images produce a full redraw. (same for large textblocks) If we can solve this, the rest may become insignificant! Please feel free to experiment, propose alternatives, or implement a better approach that can be committed ASAP! :-) -- Cheers Jorge.-