Re: Strange performance behaviour related to <span>

On Fri, Jun 17, 2016 at 11:10:24AM +0200, Sebastian Geerken wrote:
> 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!

  Great!

  BTW, I've found quite useful to include a brief description of
the patch and test cases in the hg comment, that way when I do an
"hg blame" and try to find out why a certain line of code is there
it's really helpful, and much easier to find than in a mail thread!

  As hg has no way to amend a published patch, adding a single whitespace
char, and the extended comment as a new patch did the trick.

  This comment is easily readable with "hg log -v"

-- 
  Cheers
  Jorge.-