I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work. Regards, Jeremy Henty
On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote:
I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work.
Yes, Jorge did a great job. I've not yet found any regressions and on some pages it's better than dillo1 was. Johannes
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote:
Yes, Jorge did a great job. I've not yet found any regressions and on some pages it's better than dillo1 was.
Another improvement I forgot to mention: I had several links where huge areas of whitespace appeared inside the page. These now render sensibly. The new code seems to be much better at allocating space between the rows and columns. Regards, Jeremy Henty
After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished) :) Diego. PD: I can not get scrollbar in that page. 2008/1/26, Jeremy Henty <onepoint@starurchin.org>:
On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote:
Yes, Jorge did a great job. I've not yet found any regressions and on some pages it's better than dillo1 was.
Another improvement I forgot to mention: I had several links where huge areas of whitespace appeared inside the page. These now render sensibly. The new code seems to be much better at allocating space between the rows and columns.
Regards,
Jeremy Henty
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote:
After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished)
Sadly this may a little too hasty. I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows. Jeremy Henty
On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote:
On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote:
After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished)
Sadly this may a little too hasty. I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows.
Degraded since previous dillo2 or dillo1 version? AFAIS, the main bottleneck in dillo2 still is too many redraw requests. With regard to table rendering the code is mainly O(n), so "badly degraded" would be a bug. Now, the code isn't yet optimized so there's plenty of space for improving (in the O(n) realm). Please send the test cases and their detected problems. -- Cheers Jorge.-
On Wed, Jan 30, 2008 at 10:29:48AM -0300, Jorge Arellano Cid wrote:
On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote:
I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows.
Degraded since previous dillo2 or dillo1 version?
Since dillo2 a few months ago. I have a script that scrapes a lot of RSS feeds and builds a two-column HTML table with small cells but a *lot* of rows. Looking at that page with Dillo, if I drag the window around it thrashes the CPU. Also, dragging a selection is *extremely* slow: it takes 0.5-1 second to highlight/unhighlight *each* cell. I'm pretty sure (though I have not yet made sure) that this poor rendering performance appeared quite recently.
Please send the test cases and their detected problems.
I'll submit tests and fixes for the ROWSPAN bug in a new thread, then look at rendering performance. Regards, Jeremy Henty
On Wed, Jan 30, 2008 at 10:29:48AM -0300, Jorge Arellano Cid wrote:
On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote:
On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote:
After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished)
Sadly this may a little too hasty. I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows.
Degraded since previous dillo2 or dillo1 version?
AFAIS, the main bottleneck in dillo2 still is too many redraw requests.
Yes, that's probabely true. However, I currently don't see any low hanging fruit in this area. dillo1 also redraws all the time. It is just not visible because it draws to some offscreen area first and then copies the result to the screen. And what's more important, drawing was cheaper without antialiased fonts... Johannes
With regard to table rendering the code is mainly O(n), so "badly degraded" would be a bug.
Now, the code isn't yet optimized so there's plenty of space for improving (in the O(n) realm).
Please send the test cases and their detected problems.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Jan 30, 2008 at 09:24:57PM +0100, Johannes Hofmann wrote:
On Wed, Jan 30, 2008 at 10:29:48AM -0300, Jorge Arellano Cid wrote:
On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote:
On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote:
After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished)
Sadly this may a little too hasty. I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows.
Degraded since previous dillo2 or dillo1 version?
AFAIS, the main bottleneck in dillo2 still is too many redraw requests.
Yes, that's probabely true.
However, I currently don't see any low hanging fruit in this area. dillo1 also redraws all the time. It is just not visible because it draws to some offscreen area first and then copies the result to the screen. And what's more important, drawing was cheaper without antialiased fonts...
My feeling is exactly. One cheap way to avoid redraws is to throttle them at let say 3 seconds, and to force one when the parsing is done with the full page (close time). Another, cleaner approach, may be to avoid unnecessary redraw requests from the textblock and table widgets (or other source). I haven't investigated this in detail, but for instance, Textblock::wordWrap always sets "mustQueueResize = true". If the Textblock knows that the just added contents are out of the displayed area, and that it didn't grow wider/thiner, we may avoid the request until it is displayed, or page ends, whatever comes first. Disclaimer: these are just ideas, no proof of concept yet. -- Cheers Jorge.-
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. The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it. Please note, that the provided run method was tuned for my computer, so it may need other values on slower/faster machines. Play around with other strategies! Johannes diff --git a/dw/fltkplatform.cc b/dw/fltkplatform.cc --- a/dw/fltkplatform.cc +++ b/dw/fltkplatform.cc @@ -25,6 +25,7 @@ #include <fltk/draw.h> #include <fltk/run.h> #include <fltk/events.h> +#include <fltk/Window.h> #include <stdio.h> namespace dw { @@ -185,6 +186,9 @@ container::typed::HashTable <dw::core::s new container::typed::HashTable <dw::core::style::ColorAttrs, dw::core::style::Color> (false, false); +container::typed::List <FltkPlatform> *FltkPlatform::idlePlatforms = + new container::typed::List <FltkPlatform> (0); + FltkPlatform::FltkPlatform () { layout = NULL; @@ -200,8 +204,7 @@ FltkPlatform::FltkPlatform () FltkPlatform::~FltkPlatform () { - if(idleFuncRunning) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef(this); delete idleQueue; } @@ -241,11 +244,6 @@ int FltkPlatform::textWidth (core::style FltkFont *ff = (FltkFont*) font; setfont (ff->font, ff->size); return (int) getwidth (text, len); -} - -void FltkPlatform::generalStaticIdle (void *data) -{ - ((FltkPlatform*)data)->generalIdle(); } void FltkPlatform::generalIdle () @@ -263,7 +261,7 @@ void FltkPlatform::generalIdle () if(idleQueue->isEmpty()) { idleFuncRunning = false; - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } } @@ -277,8 +275,9 @@ int FltkPlatform::addIdle (void (core::L * idle function, the passed idle function is put into a queue. */ if(!idleFuncRunning) { - add_idle (generalStaticIdle, (void*)this); idleFuncRunning = true; + idlePlatforms->removeRef (this); + idlePlatforms->append (this); } idleFuncId++; @@ -306,7 +305,7 @@ void FltkPlatform::removeIdle (int idleI } if(idleFuncRunning && idleQueue->isEmpty()) - remove_idle (generalStaticIdle, (void*)this); + idlePlatforms->removeRef (this); } @@ -409,5 +408,30 @@ void FltkPlatform::detachResource (ui::F resources->removeRef (resource); } + +int FltkPlatform::run () { + int skipped = 0; + + while (::fltk::Window::first()) { + int r = fltk::wait (0.01); + + if (r == 0 || skipped >= 50) { + skipped = 0; + + for (container::typed::Iterator <FltkPlatform> it = idlePlatforms->iterator (); + it.hasNext (); ) { + FltkPlatform *p = it.getNext (); + + p->generalIdle (); + } + + } else { + skipped++; + } + } + + return 0; +} + } // namespace fltk } // namespace dw diff --git a/dw/fltkplatform.hh b/dw/fltkplatform.hh --- a/dw/fltkplatform.hh +++ b/dw/fltkplatform.hh @@ -94,7 +94,7 @@ private: bool idleFuncRunning; int idleFuncId; - static void generalStaticIdle(void *data); + static container::typed::List <FltkPlatform> *idlePlatforms; void generalIdle(); container::typed::List <FltkView> *views; @@ -163,6 +163,8 @@ public: void attachResource (ui::FltkResource *resource); void detachResource (ui::FltkResource *resource); + + static int run(); }; } // namespace fltk diff --git a/config.h.in b/config.h.in diff --git a/src/dillo.cc b/src/dillo.cc --- a/src/dillo.cc +++ b/src/dillo.cc @@ -23,6 +23,8 @@ #include <fltk/Window.h> #include <fltk/run.h> + +#include "dw/fltkcore.hh" #include "dir.h" #include "uicmd.hh" @@ -103,5 +105,5 @@ int main(int argc, char **argv) a_Nav_push(bw, prefs.start_page); } - return fltk::run(); + return dw::fltk::FltkPlatform::run(); } diff --git a/dw/layout.cc b/dw/layout.cc --- a/dw/layout.cc +++ b/dw/layout.cc @@ -520,58 +520,61 @@ void Layout::updateBgColor () void Layout::resizeIdle () { - // Reset already here, since in this function, queueResize() may be - // called again. - resizeIdleId = -1; - - if (topLevel) { - Requisition requisition; - Allocation allocation; - - topLevel->sizeRequest (&requisition); - - allocation.x = allocation.y = 0; - allocation.width = requisition.width; - allocation.ascent = requisition.ascent; - allocation.descent = requisition.descent; - topLevel->sizeAllocate (&allocation); - - canvasWidth = requisition.width; - canvasAscent = requisition.ascent; - canvasDescent = requisition.descent; - emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + while (resizeIdleId != -1) { + // Reset already here, since in this function, queueResize() may be + // called again. + resizeIdleId = -1; - // Tell the views about the new world size. - for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { - View *view = it.getNext (); - view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); - view->queueDrawTotal (); - } + if (topLevel) { + Requisition requisition; + Allocation allocation; - if (usesViewport) { - int actualHScrollbarThickness = - (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; - int actualVScrollbarThickness = + topLevel->sizeRequest (&requisition); + + allocation.x = allocation.y = 0; + allocation.width = requisition.width; + allocation.ascent = requisition.ascent; + allocation.descent = requisition.descent; + topLevel->sizeAllocate (&allocation); + + canvasWidth = requisition.width; + canvasAscent = requisition.ascent; + canvasDescent = requisition.descent; + + emitter.emitCanvasSizeChanged (canvasWidth, canvasAscent, canvasDescent); + + // Tell the views about the new world size. + for (typed::Iterator <View> it = views->iterator (); it.hasNext (); ) { + View *view = it.getNext (); + view->setCanvasSize (canvasWidth, canvasAscent, canvasDescent); + view->queueDrawTotal (); + } + + if (usesViewport) { + int actualHScrollbarThickness = + (canvasWidth > viewportWidth) ? hScrollbarThickness : 0; + int actualVScrollbarThickness = (canvasAscent + canvasDescent > viewportWidth) ? vScrollbarThickness : 0; - - if (!canvasHeightGreater && - canvasAscent + canvasDescent - > viewportHeight - actualHScrollbarThickness) { - canvasHeightGreater = true; - setSizeHints (); - /* May queue a new resize. */ - } - // Set viewport sizes. - for (typed::Iterator <View> it = views->iterator (); - it.hasNext (); ) { - View *view = it.getNext (); - if (view->usesViewport ()) - view->setViewportSize (viewportWidth, viewportHeight, - actualHScrollbarThickness, - actualVScrollbarThickness); + if (!canvasHeightGreater && + canvasAscent + canvasDescent + > viewportHeight - actualHScrollbarThickness) { + canvasHeightGreater = true; + setSizeHints (); + /* May queue a new resize. */ + } + + // Set viewport sizes. + for (typed::Iterator <View> it = views->iterator (); + it.hasNext (); ) { + View *view = it.getNext (); + if (view->usesViewport ()) + view->setViewportSize (viewportWidth, viewportHeight, + actualHScrollbarThickness, + actualVScrollbarThickness); + } } }
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. So far I have very good results. Stay tuned...
The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it.
Committed. -- Cheers Jorge.-
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.
The other patch changes resizeIdle() a bit. As stated in the comments, resizeIdle() can queue a new resizeIdle(). So instead of drawing the preliminary layout, then change it and redraw again, we now wait until the layout is settled and then draw it.
Committed.
OK. Cheers, Johannes
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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.
Oh, after a more in-depth review I see you're only throttling when to call FltkPlatform's generalIdle. That's OK. I'm experimentin with a queueResize(bool asap)/flush(bool asap) approach. A couple of glitches remain... -- Cheers Jorge.-
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.-
Hi Jorge, On Mon, Feb 04, 2008 at 07:31:29PM -0300, Jorge Arellano Cid wrote:
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); } }
If I understand this correctly, the patch now is equivalent to removing the calls to queueDrawTotal(), where asap == false, right? With this patch I see missing screen updates e.g. when resizing the window.
(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.
First let me explain how I think the drawing and relayout is designed in dillo2. Please correct me if I'm wrong. * 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. * queueResize() calls are put into the code whenever the layout might have changed without worrying too much about performance. To make this efficient, queueResize() or queueDrawTotal() just remembers drawing or resizing should be done at some time in the future. * The idle function mechanism then does the actual work of resizing or redrawing. This way many calls to queueResize() can cause many resize operations, or they can be combined to just single resize depending on when the idle functions are called. When loading the same page, dillo can update the screen frequently if enough CPU is available, or less often, if CPU time is not available. I think this is an excellent concept :-) So what do we need to do? * Make the concept work properly. Here I think we need to improve the code where the idle functions are called so that multiple redraws are really combined especially if there is no CPU available. * 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(). * 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. 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?). Cheers, Johannes
Hi, On Wed, Feb 06, 2008 at 01:13:30PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Mon, Feb 04, 2008 at 07:31:29PM -0300, Jorge Arellano Cid wrote:
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); } }
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, ...).
With this patch I see missing screen updates e.g. when resizing the window.
Yes some glitches remain. There's still a need to add a few queueDrawTotal(true) calls in necessary places so this is solved. Once this is done, the amount of CPU usage decreases dramatically and the user can choose a refresh rate.
First let me explain how I think the drawing and relayout is designed in dillo2. Please correct me if I'm wrong.
Oh, I didn't design it so we're both exploring this area.
* 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. e.g. as place commented:
You can try with the new patch.
dillo-fltk immediate /* clear_double_buffer(); */ dillo-fltk 0:06 clear_double_buffer();
* queueResize() calls are put into the code whenever the layout might have changed without worrying too much about performance. To make this efficient, queueResize() or queueDrawTotal() just remembers drawing or resizing should be done at some time in the future.
It looks like, but there are also some unimplemented functions like startDrawing (), finishDrawing(), and flush(). Maybe they were discarded, myabe left for future implementation, or left for a second design-pass.
* The idle function mechanism then does the actual work of resizing or redrawing. This way many calls to queueResize() can cause many resize operations, or they can be combined to just single resize depending on when the idle functions are called. When loading the same page, dillo can update the screen frequently if enough CPU is available, or less often, if CPU time is not available.
I think this is an excellent concept :-)
:)
So what do we need to do?
* Make the concept work properly. Here I think we need to improve the code where the idle functions are called so that multiple redraws are really combined especially if there is no CPU available.
* 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.
* 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.
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). -- Cheers Jorge.-
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?
With this patch I see missing screen updates e.g. when resizing the window.
Yes some glitches remain. There's still a need to add a few queueDrawTotal(true) calls in necessary places so this is solved. Once this is done, the amount of CPU usage decreases dramatically and the user can choose a refresh rate.
First let me explain how I think the drawing and relayout is designed in dillo2. Please correct me if I'm wrong.
Oh, I didn't design it so we're both exploring this area.
* 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).
e.g. as place commented:
You can try with the new patch.
dillo-fltk immediate /* clear_double_buffer(); */ dillo-fltk 0:06 clear_double_buffer();
* queueResize() calls are put into the code whenever the layout might have changed without worrying too much about performance. To make this efficient, queueResize() or queueDrawTotal() just remembers drawing or resizing should be done at some time in the future.
It looks like, but there are also some unimplemented functions like startDrawing (), finishDrawing(), and flush(). Maybe they were discarded, myabe left for future implementation, or left for a second design-pass.
* The idle function mechanism then does the actual work of resizing or redrawing. This way many calls to queueResize() can cause many resize operations, or they can be combined to just single resize depending on when the idle functions are called. When loading the same page, dillo can update the screen frequently if enough CPU is available, or less often, if CPU time is not available.
I think this is an excellent concept :-)
:)
So what do we need to do?
* Make the concept work properly. Here I think we need to improve the code where the idle functions are called so that multiple redraws are really combined especially if there is no CPU available.
* 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.
* 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.
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 :-) Cheers, Johannes
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. 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. 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. 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 Jorge.-
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
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.-
Hi Jorge, On Wed, Feb 13, 2008 at 01:51:50PM -0300, Jorge Arellano Cid wrote: -- snip --
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!
Exactly. Those redraws are unnecessary and should be avoided.
Please feel free to experiment, propose alternatives, or implement a better approach that can be committed ASAP! :-)
I will try to come up with a fix, but it may take a while since I will be skiing this weekend :-) Independent from that, I'm using my last patch regarding the redraws for quite a while now and it works pretty well here. Doesn't it make dillo2 much more useable for you, or do you see negative effects with it? Cheers, Johannes
Hi,
[...] 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.
Funny how commenting out Widget::queueDrawArea() gives the same rendering (note that Widget::queueDraw() calls Widget::queueDrawArea()). When there are images a number in the hundred magnitude may be wasted. :-) -- Cheers Jorge.-
On Thu, Feb 07, 2008 at 11:45:18PM -0300, Jorge Arellano Cid wrote:
Hi,
[...] 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.
Funny how commenting out Widget::queueDrawArea() gives the same rendering (note that Widget::queueDraw() calls Widget::queueDrawArea()).
When there are images a number in the hundred magnitude may be wasted.
:-)
Well, actually is not exactly the same. Looks the same when the image is local, and doesn't render incrementaly over slow connections. -- Cheers Jorge.-
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. I'll keep on reviewing and expecting your work&comments. -- Cheers Jorge.-
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. -- Cheers Jorge.-
Jorge wrote:
OK, I committed an experimental patch that implememts the "feel" of the idea (i.e. a draw/flush scheme with a refresh rate)
It appears that the new code does not like closed bws: ... a_UIcmd_close_bw FltkViewBase::queueDrawTotal asap=0 FltkViewBase::drawTotal Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 5381)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x08094c21 in dw::fltk::FltkViewBase::drawTotal (this=0x81a5ca0) at fltkviewbase.cc:289 #2 0x08094c64 in drawTotalTimeout (data=0x81a5ca0) at fltkviewbase.cc:278 #3 0x080d58b9 in fltk::wait (time_to_wait=0.00186802843) at run.cxx:472 #4 0x080d595d in fltk::run () at run.cxx:393 #5 0x0804ee7a in main (argc=1, argv=0xbffffb44) at dillo.cc:106
On Sun, Feb 10, 2008 at 09:08:34PM +0000, place wrote:
Jorge wrote:
OK, I committed an experimental patch that implememts the "feel" of the idea (i.e. a draw/flush scheme with a refresh rate)
It appears that the new code does not like closed bws:
... a_UIcmd_close_bw FltkViewBase::queueDrawTotal asap=0 FltkViewBase::drawTotal
Program received signal SIGSEGV, Segmentation fault.
Oh, yes, a missing timeout function removal in the destructor. Patch committed. -- Cheers Jorge.-
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. 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. As stated before I would even treat all redraw requests equally and ignore the asap parameter. Cheers, Johannes
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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.-
On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote:
On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote:
I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work.
Yes, Jorge did a great job. I've not yet found any regressions and on some pages it's better than dillo1 was.
Good to know! :) -- Cheers Jorge.-
Hi, On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote:
I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work.
Yes! I'm happy to hear it has endured testing. Good. -- Cheers Jorge.-
participants (5)
-
darkspirit5000＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org -
place＠gobigwest.com