- Dillo-dev - lists.mailman3.com

image overlaps text

by jcid＠dillo.org

Hi Sebastian, On Sat, May 21, 2016 at 05:21:07PM +0200, Sebastian Geerken wrote: > On Fri, May 20, 2016, Sebastian Geerken wrote: > > Hi Jorge, > > > > On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > > > The attached tetscase is a slight variation of the previous one. > > > > > > Comparing rendering behaviour with Firefox here shows some interesting > > > facts/bugs/design-decisions: > > > > > > 1.- FF links the olive div's width to viewport width only. > > > Dillo links it to viewport and its own child width. > > > > Dillo has a rather (over-)simple definition as what do draw with the > > background color. I regard this as a low-priority issue, which can be > > solved after the next release. I was thinking more in the line of the outmost div's width side-effects on its children rendering. Anyway, this may be a different bug, read on... > > > 2.- When splitting the first sentence (in olive div), by narrowing the > > > viewport, text in the teal div is also split! > > > 3.- After 2.-, when widening the viewport, text in olive widens, but text > > > in teal not! (reload, does the trick). > > > > I'll write more on this later. > > I've looked a bit at this, and it seems to look like another case I > was working on, so it may be best to fix the latter, and hopefully the > former is fixed, too. > > I'll describe my analysis so far, which may give you a better > understanding of the code. Good news on this one! (i.e. the overlapped image/text in o4.html). After reading your description of the other problem (n33180d.html), especially the part where you wonder "why", it became clear that the code was meant to handle it, so I turned to try to find what may possible be going astray there. Short story: I have a working patch. It solves the overlap (not 1.- 2.- and 3.-). It seems there're a few different bugs here. It's not as clean as I'd like, but it already is a proof of concept. I'll try to understand the issues better and clean it up. AFAIS it can have an effect on general rendering of floats. Currently, I dont know if it's related to n33180d.html. I'll try to share my findings this monday (unless you'd like to look at it "as is" now). -- Cheers Jorge.-

May 22, 2016

image overlaps text

by sgeerken＠dillo.org

On Fri, May 20, 2016, Sebastian Geerken wrote: > Hi Jorge, > > On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > > The attached tetscase is a slight variation of the previous one. > > > > Comparing rendering behaviour with Firefox here shows some interesting > > facts/bugs/design-decisions: > > > > 1.- FF links the olive div's width to viewport width only. > > Dillo links it to viewport and its own child width. > > Dillo has a rather (over-)simple definition as what do draw with the > background color. I regard this as a low-priority issue, which can be > solved after the next release. > > > 2.- When splitting the first sentence (in olive div), by narrowing the > > viewport, text in the teal div is also split! > > 3.- After 2.-, when widening the viewport, text in olive widens, but text > > in teal not! (reload, does the trick). > > I'll write more on this later. I've looked a bit at this, and it seems to look like another case I was working on, so it may be best to fix the latter, and hopefully the former is fixed, too. I'll describe my analysis so far, which may give you a better understanding of the code. The test case is attached. Notice that there is a float within a float, with no sizes explicitly defined. Dillo (and also FF) will use the maximal width as size, as long as it fits into the available width (which is the case here). It should look like (and looks like in FF): abcdefghijkl float mnopqrstuvwx It actually is drawn by dillo like this: float abcdefghijkl mnopqrstuvwx There are two problems: 1. Why is the word "abcdefghijkl" in the second line? 2. Why is the float positioned too far right? Let's examine problem 1. I'm using RTFL (<http://home.gna.org/rtfl/>; use the latest version from SVN, not the release, and make sure you have the graphviz library installed). To enable the RTFL messages, run the dillo configure script with "--enable-rtfl". Run: $ src/dillo n33180d.html | rtfl-objview -OM -a "*" -A draw (I'm also adding "-v 'emacsclient -n %n %p'", and you may use the script rtfl-filter-out-classes.) The relevant textblock is the lower right one (some guessing, and examine the attributes). Go to the attribute "lines/0/firstWord", select the last (which is the relevant) assignment and press Ctrl+A. This way, we can focus on what has happened before the first line is eventually created. Then examine "words/0/badnessAndPenalty" (again last entry); you'll see "... vs. -31" here, which means that when calculating the badness (used for line breaking), an ideal width of -31 was assumed, which is obviously an icorrect value. The "stack trace" function (Ctrl+T) leads to "accumulateWordData", in which "calcLineBreak" is used to calculate this value. Press Ctrl+A again to hide everything behind the last command within "calcLineBreak" ("leave"). What values go into the return value? - lineBreakWidth = 194, which looks plausible. (You can examine this further: this is calculates by "getAvailWidth", which actually returns the maximal width.) - leftInnerPadding = 0 (ok) - leftBorder = 0 (ok) - rightBorder = 225, which is obviously too large. "rightBorder" goes back to the attribute "newLineRightBorder", which is set in "calcBorders". If you look at the messages here, you'll notice that the result of "getGeneratorRest" is -194, which is too small (it should be 0 here). Further examination shows: - getGeneratorWidth (this widget) = 194: ok - getGeneratorWidth (container) = 0: too small Examining the latter shows than the width of the child (194) is not yet regarded here. I'm not yet sure how to fix this best; most probably a size recalculation should be queued under certain circumstances. Sebastian

May 21, 2016

image overlaps text

by sgeerken＠dillo.org

Hi Jorge, On Fr, Mai 20, 2016, Jorge Arellano Cid wrote: > The attached tetscase is a slight variation of the previous one. > > Comparing rendering behaviour with Firefox here shows some interesting > facts/bugs/design-decisions: > > 1.- FF links the olive div's width to viewport width only. > Dillo links it to viewport and its own child width. Dillo has a rather (over-)simple definition as what do draw with the background color. I regard this as a low-priority issue, which can be solved after the next release. > 2.- When splitting the first sentence (in olive div), by narrowing the > viewport, text in the teal div is also split! > 3.- After 2.-, when widening the viewport, text in olive widens, but text > in teal not! (reload, does the trick). I'll write more on this later. Sebastian

May 20, 2016

CPU hog bug with https?

by jcid＠dillo.org

On Fri, May 20, 2016 at 09:45:30AM +0200, Diego . wrote: > Occasional problem with the text under the float seems to have gone at > www.astronautix.com too > > For example: > http://www.astronautix.com/lvs/n1.htm Ack. > Very good work. Thanks, in the name of the team. Credit where credit's Due, Sebastian made great progress with GROWS2. We support each other as we are able to. -- Cheers Jorge.-

May 20, 2016

image overlaps text

by jcid＠dillo.org

Hi Sebastian, On Sat, Apr 30, 2016 at 01:31:48PM +0200, Sebastian Geerken wrote: > On Fr, Apr 29, 2016, Jorge Arellano Cid wrote: > > On Fri, Apr 29, 2016 at 06:41:32PM +0200, Sebastian Geerken wrote: > > > On Fri, Apr 29, 2016, Nick Warne wrote: > > > > > > > > > > > > On 29/04/16 16:46, Alexander Voigt wrote: > > > > >I noticed, that in current Dillo (tip) there are cases where images > > > > >overlap surrounding text, making in unreadable. Here is an example page: > > > > > > > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > > > > > > > Strange, renders here OK (latest hg pull). > > > > > > As I wrote, this is hard to reproduce. > > > > Yes. > > > > (I can't reproduce it with your best URL :) > > > > Fortunately, today I managed to find&reduce a case that works all the time > > here. Attached it goes. Just resize horizontally to see the overlap. > > > > I hope it works there! > > Thanks, Jorge, for the perfect testcase. So far, I've tracked down the > problem, but I'm not yet sure how to fix it. Hopefully, the fix will > also solve the other issues with overlapping floats. The attached tetscase is a slight variation of the previous one. Comparing rendering behaviour with Firefox here shows some interesting facts/bugs/design-decisions: 1.- FF links the olive div's width to viewport width only. Dillo links it to viewport and its own child width. 2.- When splitting the first sentence (in olive div), by narrowing the viewport, text in the teal div is also split! 3.- After 2.-, when widening the viewport, text in olive widens, but text in teal not! (reload, does the trick). As usual, since a few years, following FF in these corner cases is the safe chioce. I'd like to dig into it with a view to learn more about rendering floats. Would you please explain a bit what you've found, which of the above points you'd recommend me to start with, and spill some suggestions on what parts of the code/design are most probably responsible for it. -- Cheers Jorge.-

May 20, 2016

Dillo_grows merged

by jcid＠dillo.org

On Thu, May 19, 2016 at 12:02:47PM -0400, Jorge Arellano Cid wrote: > 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... Committed. -- Cheers Jorge.-

May 19, 2016

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