- Dillo-dev - lists.mailman3.com

Dillo_grows merged

by jcid＠dillo.org

On Wed, May 18, 2016 at 11:11:17PM +0200, Sebastian Geerken wrote: > > > > The attached patch works OK for the text search, but I don't know > > > > whether it fits with the overall design. > > > > > > > > It *seems to fit* but I'd prefer you to check it. ;) > > > > > > I've just pushed a variant of your patch, please give it a try. > > > > Much better! > > > > I still wander what a negative sectionIndex means (0 is in flow). > > It takes negative values sometimes. It should be commented. > > It happens when iterating back gets behind 0. Likewise, it may become > larger than NUM_SECTIONS - 1, when iterating forward. Yep, it also happens with "index". > > > What should getPart() do upon a negative sectionIndex? > > It should not be called, actually. This should be checked, first. OK, I've rewrote next() and prev() with full protection and made clear semantics for the corner cases in setValues(). As a side effect, the code got shorter and easier to read. Now in testing phase... -- Cheers Jorge.-

May 19, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Thu, May 19, 2016 at 06:06:32AM +0200, Sebastian Geerken wrote: > On Mi, Mai 18, 2016, Jorge Arellano Cid wrote: > > On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > > > It also seems to fix the problems with > > > netzpolitik.org and nachdenkseiten.de. (Others please check this, > > > too.) > > > > Both sites render blazingly fast here. > > The (occasional) problem with the text under the float seems to have > gone. Oh, I see. nachdenkseiten.de showed the bug 4 of 4 times without the patch and none with patched version. netzpolitik.org doesn't show the bug here. Neither from net, nor locally. -- Cheers Jorge.-

May 19, 2016

CPU hog bug with https?

by sgeerken＠dillo.org

On Mi, Mai 18, 2016, Jorge Arellano Cid wrote: > On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > > It also seems to fix the problems with > > netzpolitik.org and nachdenkseiten.de. (Others please check this, > > too.) > > Both sites render blazingly fast here. The (occasional) problem with the text under the float seems to have gone. Sebastian

May 19, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote: > Hi Jorge, > > On Di, Mai 17, 2016, Jorge Arellano Cid wrote: > > On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > > > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > > > Hi, > > > > > > > > If I start current dillo with [1], an https dialog springs > > > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > > > answering "cancel" allows reading the page with no problems. > > > > > > > > FWIW, I've done that lots of times with other sites, and this is the > > > > first CPU hog I get accross. > > > > > > > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > > > > > I can reproduce this. However, profiling shows rather problems in the > > > rendering code (dw::core::Widget::queueResize etc.), so the problem is > > > probably not related to HTTPS. > > > > > > Also, mirroring this page ("wget -pkH") and displaying it locally > > > shows the same symptoms. > > > > > > Looks that this belongs rather on my todo list. > > > > Good news on this one. > > > > Patch committed! > > Thanks for the good work! You're welcomed. I aim at reducing your workload so you can focus on corework. BTW, the speed improvements introduced with GROWS2, and the way I picture dillo's rendering once floats/absolutes work right are quite motivating. ;) > It also seems to fix the problems with > netzpolitik.org and nachdenkseiten.de. (Others please check this, > too.) Both sites render blazingly fast here. > > [...] > > It was hard to find, sometimes backtraces gave near 85 or more nested calls, > > full of different functions. There was no CPU lock because it finally solved > > the page (after more than two minutes in my machine). > > > > It took a few days of work, by reducing the testcase (a slashdot page) by: > > * removing the scripting > > * removing one stylesheet completely (no bug without CSS). > > * removing sections of the HTML code > > while checking the bug was still reproducible. And checking the backtrace > > stack from gdb from time to time. gprof may have served also, but as there > > where so many functions I decided to keep reducing the case. > > > > This is a trial&error iteration process. > > > > At some point I could clean the testcase enough to run tidy on it, and > > no, it wasn't a tag soup corner case. > > > > Back to reducing the testcase. It started to solve in less time, but still > > hogging my CPU for near 20 secs.. > > > > Then suddenly at some point, gdb's backtrace was still near the hundred > > in depth, but a few functions remained. Studying the code in the involved > > functions made me finally spot the hiding bug. Trivial to fix, but very > > hard to find. > > > > For this case, what took more than 2 minutes to render, now takes near 1/8 > > second. ;-) > > Yes, this is the usual way I track down bugs, too. This is much > simpler for rendering bugs, which can be preserved while simplifying > the page. This kind of bug is much more difficult since the effect > (taking too much time) vanishes the more the simpler the page gets. Good point. -- Cheers Jorge.-

May 18, 2016

Dillo_grows merged

by sgeerken＠dillo.org

> > > The attached patch works OK for the text search, but I don't know > > > whether it fits with the overall design. > > > > > > It *seems to fit* but I'd prefer you to check it. ;) > > > > I've just pushed a variant of your patch, please give it a try. > > Much better! > > I still wander what a negative sectionIndex means (0 is in flow). > It takes negative values sometimes. It should be commented. It happens when iterating back gets behind 0. Likewise, it may become larger than NUM_SECTIONS - 1, when iterating forward. > What should getPart() do upon a negative sectionIndex? It should not be called, actually. This should be checked, first. Sebastian

May 18, 2016

CPU hog bug with https?

by sgeerken＠dillo.org

Hi Jorge, On Di, Mai 17, 2016, Jorge Arellano Cid wrote: > On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > > Hi, > > > > > > If I start current dillo with [1], an https dialog springs > > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > > answering "cancel" allows reading the page with no problems. > > > > > > FWIW, I've done that lots of times with other sites, and this is the > > > first CPU hog I get accross. > > > > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > > > I can reproduce this. However, profiling shows rather problems in the > > rendering code (dw::core::Widget::queueResize etc.), so the problem is > > probably not related to HTTPS. > > > > Also, mirroring this page ("wget -pkH") and displaying it locally > > shows the same symptoms. > > > > Looks that this belongs rather on my todo list. > > Good news on this one. > > Patch committed! Thanks for the good work! It also seems to fix the problems with netzpolitik.org and nachdenkseiten.de. (Others please check this, too.) I've one case in my list, which is already analyzed. More on this later. > I'd like to comment a bit on this bugfix for those that would like to > help making patches for dillo. You can check the patch and verbose > log with: "hg log -vp|less". > > It was hard to find, sometimes backtraces gave near 85 or more nested calls, > full of different functions. There was no CPU lock because it finally solved > the page (after more than two minutes in my machine). > > It took a few days of work, by reducing the testcase (a slashdot page) by: > * removing the scripting > * removing one stylesheet completely (no bug without CSS). > * removing sections of the HTML code > while checking the bug was still reproducible. And checking the backtrace > stack from gdb from time to time. gprof may have served also, but as there > where so many functions I decided to keep reducing the case. > > This is a trial&error iteration process. > > At some point I could clean the testcase enough to run tidy on it, and > no, it wasn't a tag soup corner case. > > Back to reducing the testcase. It started to solve in less time, but still > hogging my CPU for near 20 secs.. > > Then suddenly at some point, gdb's backtrace was still near the hundred > in depth, but a few functions remained. Studying the code in the involved > functions made me finally spot the hiding bug. Trivial to fix, but very > hard to find. > > For this case, what took more than 2 minutes to render, now takes near 1/8 > second. ;-) Yes, this is the usual way I track down bugs, too. This is much simpler for rendering bugs, which can be preserved while simplifying the page. This kind of bug is much more difficult since the effect (taking too much time) vanishes the more the simpler the page gets. Sebastian

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

I wrote: > On Wed, May 18, 2016 at 08:18:52PM +0100, Nick Warne wrote: > > AS to your question, what I don't understand is why there is a section > > for tab colours, and then later in the default theme section (which is > > active) more options for tab colour options? > > > > Perhaps move the 'stand-alone' tab colour options after the themes, so > > if the all the themes are #'ed out, these will take precedence? > > > > Or why have them at all? > > That's a good point. It looks like they evolved suboptimally. > First I was introducing color settings, and then Jorge made some > themes, and a theme became default. I'll clean it up. Hmm. I came up with something that makes it less inviting to set the individual preferences right there, but perhaps not as uninviting as I would prefer: # UI colors # Note that FLTK may sometimes override colors, generally for contrast and # readability. # # ui_fg_color, ui_main_bg_color, ui_text_bg_color, and ui_selection_color # map to concepts in the underlying FLTK toolkit which are described as: # "the default foreground color...used for labels and text", "default # background color", "the default background color for text, list, and # valuator widgets", and "the default selection/highlight color". They # sometimes have other uses in the more complex FLTK widgets. # # ui_button_highlight_color is the background used when the mouse cursor is # over a button. By default, this is a lightened version of the main # background color. # # ui_tab_active_fg_color and ui_tab_active_bg_color are used for the current # tab. By default, they are the main foreground color and the text background # color, respectively. # # ui_tab_fg_color and ui_tab_bg_color are used for the other tabs. By default, # they are the main foreground color and the main background color, # respectively. # # Note to packagers: leaving these variables for the system to guess # gives different results in different environments, so we played it safe # by defining the traditional colors. Please choose the color theme that # better fits your distro. # # Gray theme (traditional) # ...

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Wed, May 18, 2016 at 08:18:52PM +0100, Nick Warne wrote: > AS to your question, what I don't understand is why there is a section > for tab colours, and then later in the default theme section (which is > active) more options for tab colour options? > > Perhaps move the 'stand-alone' tab colour options after the themes, so > if the all the themes are #'ed out, these will take precedence? > > Or why have them at all? That's a good point. It looks like they evolved suboptimally. First I was introducing color settings, and then Jorge made some themes, and a theme became default. I'll clean it up.

May 18, 2016

New tab colours - suggestion

by nick＠linicks.net

On Wed, 18 May 2016 18:52:13 +0000 eocene <eocene at gmx.com> wrote: > > All fixed now using: > > > > ui_tab_active_bg_color=lightgrey > > ui_tab_bg_color=#808080 > > I wonder whether there'd be any value in printing a MSG complaining > when dillorc sets something more than once (search_url excepted). Actually, I am now using: ui_tab_active_fg_color=brown ui_tab_bg_color=#909090 which works great. AS to your question, what I don't understand is why there is a section for tab colours, and then later in the default theme section (which is active) more options for tab colour options? Perhaps move the 'stand-alone' tab colour options after the themes, so if the all the themes are #'ed out, these will take precedence? Or why have them at all? Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Wed, May 18, 2016 at 04:34:50PM +0100, Nick Warne wrote: > On Tue, 17 May 2016 19:05:34 +0000 > eocene <eocene at gmx.com> wrote: > > (Also check that > > they aren't being set again farther down in dillorc.) > > Thanks, I didn't thing of looking further down - the theme was setting > it. > > All fixed now using: > > ui_tab_active_bg_color=lightgrey > ui_tab_bg_color=#808080 I wonder whether there'd be any value in printing a MSG complaining when dillorc sets something more than once (search_url excepted).

May 18, 2016