Hi Jorge,
Still, Dw should handle this. Look at this example:
(for i in $(seq 1 20); do echo '<div style="float:left"><div></div><div style="display:table"></div>'; done) > tmp.html; src/dillo tmp.html
Here, only some <div>s at the end are open (and it is simple to make the snippet correct HTML), but it still takes much time. This looks still like a Dw problem, especially since it is much faster if you leave the float definition away.
Yes, I see.
There's indeed a problem in Dw.
After some inspired reflections on the exponential nature of the time taken, and the corresponding tests&experiments, I got to a simple patch that solves all the cases we've seen so far in this thread!
It makes all cpu hog cases render as fast as expected, and even makes some "unrelated" sites I visit render twice faster or so.
I'm not postulating this to be *the* correct solution, but is a strong hint as to what is wrong. I didn't want to mess with mustQueueResize subtleties, so I'm more than happy with this one-liner:
diff -r bcf30ff0896c dw/textblock.cc --- a/dw/textblock.cc Thu Jun 16 16:27:56 2016 -0400 +++ b/dw/textblock.cc Thu Jun 16 23:21:40 2016 -0400 @@ -3034,7 +3034,8 @@ void Textblock::queueDrawRange (int inde
void Textblock::updateReference (int ref) { - queueResize (ref, false); + if (lines->size ()) + queueResize (ref, false); }
HTH.
Committed, thanks for the good work! I've looked at this problem, too, and found out that the interaction between queueResize and markSizeChange was not perfect. I've not yet examined how it works now, but the performance problems seem to be solved (including the original case), so I'll assign a lower priority to this. Sebastian