Hi Johannes, On Sun, Feb 03, 2008 at 06:58:23PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sun, Feb 03, 2008 at 02:44:56PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Fri, Feb 01, 2008 at 07:11:31PM +0100, Johannes Hofmann wrote:
Hello,
let's get more agressive regarding these excessive redraws :-)
Below are two patches. The first one adds a own run method to FltkPlatform. It is pretty similar to what fltk delivers, but this way we can tweak it as we like. Especially when to call our idle functions.
I'm experimenting with another approach because AFAIU throttling FLTK idle functions not only affects drawing code.
My patch does not throttle FLTK idle functions. It just does not use FLTK idle function mechanism for dillo. It uses an own mechanism so we can tweak it for our needs independent from what FLTK does.
So far I have very good results. Stay tuned...
Great.
Well an experimental prototype was committed. The original idea here was to use this new API: void Textblock::flush (bool asap) void FltkViewBase::queueDrawTotal (bool asap) (asap = "As soon as possible") and to call the function inmediately when "asap" is true and to otherwise delay to a tunable number of seconds. After some tests it showed extraordinarily effective. For instance testing with the "All" directory from: http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.1... it was roughly using 2 to 3 times less CPU (in my notebook) than using the FltkPlatform::generalIdle() throttling patch. Some glitches remained, and while I was working on it, the test server above went down... :( I got a big surprise when after some more tests, it worked quite well when ignoring everything but calls with asap=true ! :-) For instance, now the code reads: void FltkViewBase::queueDrawTotal (bool asap) { static time_t lastRedraw = 0; //if (asap || time(0) > lastRedraw + 2) { if (asap) { redraw (DAMAGE_EXPOSE); lastRedraw = time(0); } } (lastRedraw is not used). The patch is much simpler than it looks. Many lines are just for adding the extra parameter. Images on long pages still queue a resize that produces a total redraw. i.e when an image outside the viewport resizes, the viewport is redrawn causing flickering. This is not completely trivial because the image resize may change the size of the parent widget, and the parent widget may affect the viewable area. If this can somehow be avoided, for instance testing whether the parent widget changes its size, it'd be great. This part of the code clearly needs a review. I wanted to commit early so you guys have the chance to play with it. -- Cheers Jorge.-