- Dillo-dev - lists.mailman3.com

Good news in dillo's rendering!

by sgeerken＠dillo.org

On Mi, Jul 13, 2016, Jorge Arellano Cid wrote: > GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. > This is a very powerful and flexible concept whose design allows > floats, layers (and absolutes in the future, and more). It has > proven very fast so far, even without optimizations. It's actually called "SRDOP" ("Size Requisitions Depending On Positions). See - http://www.dillo.org/dw/html/dw-grows.html - http://www.dillo.org/dw/html/dw-size-request-pos.html As to current bugs, most of them fall into either one category: 1. missing rendering updates: this results in rendering errors (wrong positions etc.); 2. inefficient (too many) updates: this results in CPU hogging. You see that these are complementary. :-) The focus should now be on the first category, and I've still at least one open issue here, which is neither addressed by Jorge's patches. Problems from the second category are best fixed after this. Sebastian

July 17, 2016

cppcheck on Dillo source

by sgeerken＠dillo.org

On Di, Jul 12, 2016, Jorge Arellano Cid wrote: > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > in some patches I have, which also silence cppcheck. But maybe the > original construct was meant for adding more options (like absolute > positioned floats), but those may end in a third floats array, so I'm > not sure. Is it safe to use the above construct, or should I leave it > as is? OOFFloatsMgr only deals with floats, so it should be safe. However, I'd like to keep assertNotReached() there, to make debugging easier. Sebastian

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Hi there, OK, the patches were just committed, there're four instead of two and the last one has the full test suite results inside the comments in Hg. These patches work very well so far. The idea is to get your testing and feedback. I still have some ideas and cleanups for them, but that will take more time, and this set is already working and very fast. Enjoy! PD: a bit overworked Jorge. :-P -- Cheers Jorge.-

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

On Wed, Jul 13, 2016 at 01:37:12PM -0400, Jorge Arellano Cid wrote: > [...] > @Sebastian: Problem #10 is not related to GROWS2, but a three > year old bug discovered during the tests. So let's get it done > first. How to reproduce it: Go to [2], wait a bit for most images > to load, then use "find text" to find the "re-re" string, scroll > a bit downwards to find the image and center it. Go back then > forward; no image! But dillo thinks it *is* there so move the > cursor to the center of the page and you'll see the hand cursor, > wait for the tooltip and drag it a bit downwards to the right. > Dillo will repaint from the image data. > Bisect shows the bug was introduced by #2863. Attached is a > simple concept patch for it. Please review/fix/commit, as I don't > know the updated invariants of resize idle. > > > [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html > [2] http://tinyurl.com/huvf6pn As usual, the attachment arrives later... ;) -- Cheers Jorge.-

July 13, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Hi there, Here go some good news. Originally I was to send this internally to the core devs, but as we've benefitted from the feedback of active users in the list, and their experiences with the patches (before/afterwards), on the sites they usually browse, it looks like a good idea to do it again. Since June 6, when this thread [1] was started by Sebastian, I've been investigating/working in problems related to it. This led to some extensive rendering tests that catched a laundry list of problems with our current tip (#4643 today). This is a list with brief explanations, taken from the testing data tables I've gathered so far: Problems: 1: overwrites text with images. 2: crops images (aspect ratio). 3: different layout. 4: overwrites text with text float. 5: overwrites text with text. 6: CPU HOG with: tmp.num.html, tmp.num.small.html 7: Missing page sections (sometimes works for the same page). 8: Small images cut in two sometimes ("ESP", "CRO", ...) 9: Wrong aspect ratio for images (text line height) 10: Page drawn with offset (but browser thinks other section is on screen). There're test cases for each one, and most of them were taken and reduced from real pages. Having reduced test cases is good, reduced and isolated tests is better, but the good news is that I have a couple of patches that solve all of them! I'm not saying dillo will be error-free hereafter, but that the root of a whole family of problems has been found and fixed, and this will make future testing much simpler. GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. This is a very powerful and flexible concept whose design allows floats, layers (and absolutes in the future, and more). It has proven very fast so far, even without optimizations. Well the patches are two simple but deep changes in the way markSizeChange() and queueResize() interact. The patch idea is close to graph coverage recursions (with pruning), applied to the widget tree. I'd like to commit it, upload the test suite I'm using, and show the testing data tables I've gathered so everyone can check it with their use cases and report on it. @Sebastian: May I, or would you prefer to review them before? (the patches are the "middle ground" you mentioned. Solve the dw hog problems at dw level, not in the parser, and reuse code you've already seen. A couple of days should be enough to review) @Sebastian: Problem #10 is not related to GROWS2, but a three year old bug discovered during the tests. So let's get it done first. How to reproduce it: Go to [2], wait a bit for most images to load, then use "find text" to find the "re-re" string, scroll a bit downwards to find the image and center it. Go back then forward; no image! But dillo thinks it *is* there so move the cursor to the center of the page and you'll see the hand cursor, wait for the tooltip and drag it a bit downwards to the right. Dillo will repaint from the image data. Bisect shows the bug was introduced by #2863. Attached is a simple concept patch for it. Please review/fix/commit, as I don't know the updated invariants of resize idle. [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html [2] http://tinyurl.com/huvf6pn -- Cheers Jorge.-

July 13, 2016

cppcheck on Dillo source

by sgeerken＠dillo.org

> > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. > > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I've looked at this, and this is rather Johannes' code. I'm not sure whether negative may cause troubles. Sebastian

July 12, 2016

cppcheck on Dillo source

by nick＠linicks.net

On Tue, 12 Jul 2016 15:02:31 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi Nick, > > On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck > > on Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and > > attached it as a plain text file. > > Thanks for the report. I personally didn't know of cppcheck. I have used it in the past - a few years ago, but as I say I was bored so found something to do... > We have used several code cleanup tools in the past and we usually > honour them as sometimes they catch important flaws. > > A bunch of patches was just committed. You may peruse them with > "hg log -vp" for the details/explanations. Good stuff. I watch the dillo hg site anyway as I like to see (and learn) all this C++ stuff. > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I looked and looked at that, but alas, don't understand why it's wrong/right :) > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) > > Memory leak: eit3 > > Done. > > AFAICS, this is a false positive. > Patched to please cppcheck anyway. Yes, even I got that, but wasn't sure. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) > > Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) > > Uninitialized variable: X in md5.c > > Untouched: I'm not md5 savvy. Maybe corvid. Nor am I. I looked a lot at that code, and K[] whatever doesn't seem to be declared anywhere (with my little knowledge). Strange GCC doesn't squinny on that one? Thanks, 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"

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi, On Sat, Jul 09, 2016 at 03:28:25PM +0100, Nick Warne wrote: > On Sat, 9 Jul 2016 12:35:10 +0100 > Nick Warne <nick at linicks.net> wrote: > > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck on > > Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and attached > > it as a plain text file. > > > > Keep up the great work guys and thanks! > > > > Nick > > OK, updating cppcheck to 1.74, I ran it again. A new error appears, but > I don't know if it is a false positive, as I still don't really > understand C++ (but do get the logic of function calls vs void etc.: > > Checking ../../slackbuilds/dillo/hg/dillo/src/ui.cc... > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:574]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:588]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > > Now, the call is: > > make_filemenu_button(); > > to: > > Fl_Widget *UI::make_filemenu_button() > > which returns (btn) > > so is that correct? Where does (btn) go in the calling function - or > what does it do? Patch committed. It wasn't necessary anymore. Most probably it remained from a time when it was used. Now they are stored in local variables so it's safe to make the function void. -- Cheers Jorge.-

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi Nick, On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > Hi all, > > While waiting for the Tour De France to start on TV, I ran cppcheck on > Dillo source for something to do - a few errors were picked up! > > I have compacted the findings (with two comments from me)and attached it > as a plain text file. Thanks for the report. I personally didn't know of cppcheck. We have used several code cleanup tools in the past and we usually honour them as sometimes they catch important flaws. A bunch of patches was just committed. You may peruse them with "hg log -vp" for the details/explanations. > Checking ../../slackbuilds/dillo/hg/dillo/dpi/file.c... > [../../slackbuilds/dillo/hg/dillo/dpi/file.c:356]: (error) syntax error > > if S_ISDIR (finfo->mode) { > Nick-> maybe?: > if (S_ISDIR (finfo->mode)) { Done. > Checking ../../slackbuilds/dillo/hg/dillo/dpid/dpid.c... > [../../slackbuilds/dillo/hg/dillo/dpid/dpid.c:465]: (error) Resource leak: dpidrc_stream > > return -1; > Nick-> maybe?: > return (-1); Done. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer Sebastian to double check it. Not committed. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) Memory leak: eit3 Done. AFAICS, this is a false positive. Patched to please cppcheck anyway. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat Well, the code should never reach there. Not changed. @Sebastian, BTW, coincidentally I'm using something like: SortedFloatsVector *list; list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; Float *vloat = list->get (getFloatIndexFromSubRef (ref)); in some patches I have, which also silence cppcheck. But maybe the original construct was meant for adding more options (like absolute positioned floats), but those may end in a third floats array, so I'm not sure. Is it safe to use the above construct, or should I leave it as is? > Checking ../../slackbuilds/dillo/hg/dillo/lout/container.cc... > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:143]: (error) Common realloc mistake: 'array' nulled but not freed upon failure > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:177]: (error) Common realloc mistake: 'array' nulled but not freed upon failure Done. > Checking ../../slackbuilds/dillo/hg/dillo/lout/misc.cc... > [../../slackbuilds/dillo/hg/dillo/lout/misc.cc:172]: (error) Common realloc mistake: 'bits' nulled but not freed upon failure Done. > Truck loads of: > Checking ../../slackbuilds/dillo/hg/dillo/src/md5.c: ARCH_IS_BIG_ENDIAN... > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) Uninitialized variable: X > in md5.c Untouched: I'm not md5 savvy. Maybe corvid. -- Cheers Jorge.-

July 12, 2016

Problem related to generated content

by sgeerken＠dillo.org

At least it can be worked around by the user by switching off CSS, so this is not a blocker for a new release. Sebastian On Di, Jul 05, 2016, Sebastian Geerken wrote: > Hi! > > I've come upon an interesting problem. Consider this HTML (stripped > down from a real world example): > > <head> > <style> > .fc:after { > content: ""; > display: block; > clear: both; > } > </style> > </head> > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Firefox (and probably other browsers) renders black text "main" on > white background above white text "footer" on dark gray background. > Dillo 3.0.5 does the same, for the simple reason that it does not > support floats. Dillo 3.1-dev, however, renders black text "main" and > white text "footer" side by side on dark gray background, because > "main" is within a float. (Which is, of course, difficult to read.) > > The reason why Firefox renders this as it does: the definition within > <style> generates something like a block element before the text > containing "footer", with "clear: both" as CSS attributes; something > like: > > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="clear:both"></div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Aside from the fact that dillo has still problems with this ("footer" > is too much to the right; I'll investigate this independently), this > shows that dillo's limited capabilities regarding generated content, > together with floats, causes some unpleasing rendering errors, which > are furthermore laborious to analyse (and thus not so simple to > be ignored). Has someone a feasible idea to deal with this? > > Sebastian > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 10, 2016