On Mon, Feb 11, 2008 at 06:52:42AM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sun, Feb 10, 2008 at 03:43:10PM -0300, Jorge Arellano Cid wrote:
On Fri, Feb 08, 2008 at 02:42:23PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
[...] * Of course we still should reconsider each call to queueDrawTotal() or queueResize() and verify whether it is really necessary. However I think we should favor correctness over speed. That means, whenever the layout might have changed, we must call queueResize().
Sure. The patch is not complete. After adding the missing flushes it should work OK. And refresh_delay would help to set the desired behaviour.
I just committed some missing flushes so now the code updates the screen ASAP when finishing a bare image URL, a plain text page, and after the viewport resizes.
Basically it behaves as "update on finish" (except that images still queue a drawTotal so they update the whole canvas while loading).
Adding a tiemout to update periodically is easy, and thus the model would be more or less complete. Although it's simple (I've done it in my tree for testing), the CVS "as is" is the best to spot the bugs.
OK, I committed an experimental patch that implememts the "feel" of the idea (i.e. a draw/flush scheme with a refresh rate)
The rate can be set in fltkviewbase.cc:48. The default value is 2 seconds (the idea is to make it a preference).
There's still a lot to review and fix. In fact these are calls to drawTotal, and most of them are image updates that should be ignored when the image is out of the screen and doesn't resize the parent widget.
If refresh rate is set to zero, behaviour gets like before the patch (storming updates). If it's set to a high value behaviour gets like a raw draw/flush scheme.
Interesting to see that altough many unnecessary update calls remain in the code, flickering is reduced a lot, and it starts to feel comfortable without double buffer.
I'll keep on reviewing and expecting your work&comments.
Comments, patches, fixes are welcomed.
Yes, that's the way to go I think.
Which way?
The decision of when to draw should be done in a central function. Whether based on a timeout like in your current implementation or some other method is used to decide when to draw needs to be seen.
Yeah, a central function looks like a good idea. (see my previous email for some things this function should consider).
As stated before I would even treat all redraw requests equally and ignore the asap parameter.
Could be. If it tackles the problems explained in the former email. -- Cheers Jorge.-