October 2007 - Dillo-dev - lists.mailman3.com

Errata and comments

by bogus＠does.not.exist.com

Hi, Errata: -./autogen.sh -make +./autogen.sh +./configure +make Comments: In the old laptop (Pentium I, 233Mhz) scrolling is much better with the patch. This is, without patch, the CPU is hogged by pressing the scroll arrow and holding it down. It even keeps scrolling after releasing the button (keyb buffer). The patched version uses near 80% of the CPU (not 100%) and stops when releasing. In the same laptop, the over-link-quick-switch-from-arrow-to-hand (i.e. Get a directory listing and move the mouse across the links steadily) rises CPU usage to near 60%. Thre's a bug somewhere... -- Cheers Jorge.-

Oct. 11, 2007

New CVS repository and patches

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Thu, Oct 11, 2007 at 03:22:50PM -0400, Johannes Hofmann wrote: > Hi There! > > Once again, thanks for the patches and keep them flowing. > > The new CVS repository is up and updated with the patches: > > e.g. (with "-cur" terminated directories being the working directories) > > alias dcvs='cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo' > dcvs co dillo2 > dcvs co dw2 > cp -r dillo2 dillo2-cur > cp -r dw2 dw2-cur > ln -s dw2-cur dw-testbed > find dw2-cur -name CVS -exec rm \{\} \; > find dillo2-cur -name CVS -exec rm \{\} \; > cd dw2-cur > ./autogen.sh > make > cd ../dillo2-cur > ./autogen.sh > make Great, but it keeps asking for a password, am I missing something? > > > Here follow my comments on the patches. > Please test this CVS code and send feedback: > > > > [Johannes wrote] > > * the namespace "signal" in dw-testbed/lout/signal.hh conflicts with > > the declaration in /usr/include/sys/signal.h: > > __sighandler_t *signal (int, __sighandler_t *); > > I renamed the namespace to loutsignal. > > Johannes: please send me the patch for this. As only I seem to have these problems it might well be a problem of DragonFly BSD. So I would like to check that first before changing the nice an simple names in the lout library. > > [Johannes wrote] > > here is a new version of dillo-fltk scroll performance > > improvements. This patch is against vanilla dillo-fltk. > > > > New in this patch: > > > > * Hotkey bindings for arrow keys, Home- and EndKey. > > This only works when the focus is on the > > display area. > > > > * Only unclipped area is exposed which improves performance on > > large pages (e.g. http://www.w3.org/TR/xslt) > > > > * Limit scrolling to reasonable values. > > It improves not only performance on large pages but also avoids > overlapped rendering. Applied. Great. I will try to add some more performance improvements. > > > [Matthias wrote] > > Fine! Only using the arrow keys is quite slow and consumes all CPU time > > on my machine. In contrast, srolling with the old Dillo was quick and > > produced almost no CPU load. > > > > A question: Would it be difficult to add mouse wheel support as well? > > On my machine that does not work. (Or is thia a configuration issue > > regarding FLTK?) > > Dillo1 didn't render antialiased text, and was heavily optimized. The > optimization phase of rendering in dillo2 has just started (thanks > Johannes :). I hope we can tune it to a dillo1 similar CPU-consumtion. Yes, for me my patch improves performance, but we are not yet at the level of dillo1. > > > [Matthias wrote] > > Compilation on Debian Etch worked well. I had to use the "--x-includes" > > and "--x-libraries" options when configuring FLTK, and the test glpuzzle > > did not compile. > > I'm also using Etch here and didn't need those options. I also have a > running glpuzzle. The CPU, hogs when scrolling on vanilla but not > with the scrolling patch, and entities work. I also don't experience > CPU-hogs from the over-link-quick-switch-from arrow-to-hand test. Maybe this > is related to something not installed or not configured in your machine... > (This system has: x11proto-gl-dev, freeglut3, freeglut3-dev, libxft2, > libxft2-dev, libgl1-mesa-{dev,dri,glx} among others that I don't know > whether relevant or not! ;). > > BTW, I'm testing on a fast machine. It will be interesting to see what > the old one produces. > > > [Johannes wrote] > > Mouse wheel is a matter of binding. Place your mouse pointer over the > > scroll bar and use the mouse wheel (it needs to be bound to the viewport). > > > > It is slow, because the default linesize (the amount a scrollbar > > scrolls when pushing on the arrow is 1. I could change that, but > > what would be a reasonable value? > > The height of a word in normal text (i.e. line height). We know the > font and font factor from dillorc2 (or defaults). This number is a good > candidate. Ok, I will try to add this. > > > ---------------- > Side Note to all: Have you right-clicked over the search button? :-) Hey cool! Is nobody else experiencing the problems with negative hash-values? Anyway, here is the small patch again: diff -r a9312b9e22c6 dw-testbed-0.0.43j/lout/container.hh --- a/dw-testbed-0.0.43j/lout/container.hh Mon Oct 01 18:37:12 2007 +0200 +++ b/dw-testbed-0.0.43j/lout/container.hh Mon Oct 01 19:35:34 2007 +0200 @@ -212,7 +212,7 @@ private: private: inline int calcHashValue(object::Object *key) { - return key->hashValue() % tableSize; + return abs(key->hashValue()) % tableSize; } protected: Cheers, Johannes

Oct. 11, 2007

New CVS repository and patches

by bogus＠does.not.exist.com

Hi There! Once again, thanks for the patches and keep them flowing. The new CVS repository is up and updated with the patches: e.g. (with "-cur" terminated directories being the working directories) alias dcvs='cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo' dcvs co dillo2 dcvs co dw2 cp -r dillo2 dillo2-cur cp -r dw2 dw2-cur ln -s dw2-cur dw-testbed find dw2-cur -name CVS -exec rm \{\} \; find dillo2-cur -name CVS -exec rm \{\} \; cd dw2-cur ./autogen.sh make cd ../dillo2-cur ./autogen.sh make Here follow my comments on the patches. Please test this CVS code and send feedback: > [Johannes wrote] > * the namespace "signal" in dw-testbed/lout/signal.hh conflicts with > the declaration in /usr/include/sys/signal.h: > __sighandler_t *signal (int, __sighandler_t *); > I renamed the namespace to loutsignal. Johannes: please send me the patch for this. > [Vincent wrote (va_list issue)] > Sure, though i'm not at all sure this is the correct way to fix this > issue. Vincent: AFAIS, the problem is looping without the va_copy, so the patch is OK. Anyway, please test the CVS code and tell us how it works. > [Andreas wrote] > Ok, then I got it to compile finally for my ipaq with familar 0.8.4 on it. > I runs with X-forwarding so that I get the window on my notebook display. > But it segfaults without x forwarding: Andreas: please let us know the procedure when you have cleaned it up. > [Alexander wrote (strndup)] > Hm, right. I had used malloc() in my replacement function, but with > calloc() it is indeed unnecessary. > > I have wrapped this in autoconf, see attached patch. I also made > autoconf in dillo and dw-testbed check for the path to the perl binary > and substitute it in dpidc and Doxyfile, respectively, see other patch. > Actually, these patches can't simply be applied: first, > dillo-f15/dpid/dpidc and dw-testbed-0.0.43j/Doxyfile have to be moved > to *.in. Alexander: as strndup is a GNU extension, and we have kept the code as portable as possible, I just added the wrapper for it based on the patch. With regard to Perl, I'd like to get rid of that dependence either with bash (if possible) or C. BTW, if Sebastian agrees it may also be a good idea to use Dlib in dw2. That way those problems could be layered down... > [Johannes wrote] > here is a new version of dillo-fltk scroll performance > improvements. This patch is against vanilla dillo-fltk. > > New in this patch: > > * Hotkey bindings for arrow keys, Home- and EndKey. > This only works when the focus is on the > display area. > > * Only unclipped area is exposed which improves performance on > large pages (e.g. http://www.w3.org/TR/xslt) > > * Limit scrolling to reasonable values. It improves not only performance on large pages but also avoids overlapped rendering. Applied. > [Matthias wrote] > Fine! Only using the arrow keys is quite slow and consumes all CPU time > on my machine. In contrast, srolling with the old Dillo was quick and > produced almost no CPU load. > > A question: Would it be difficult to add mouse wheel support as well? > On my machine that does not work. (Or is thia a configuration issue > regarding FLTK?) Dillo1 didn't render antialiased text, and was heavily optimized. The optimization phase of rendering in dillo2 has just started (thanks Johannes :). I hope we can tune it to a dillo1 similar CPU-consumtion. > [Matthias wrote] > Compilation on Debian Etch worked well. I had to use the "--x-includes" > and "--x-libraries" options when configuring FLTK, and the test glpuzzle > did not compile. I'm also using Etch here and didn't need those options. I also have a running glpuzzle. The CPU, hogs when scrolling on vanilla but not with the scrolling patch, and entities work. I also don't experience CPU-hogs from the over-link-quick-switch-from arrow-to-hand test. Maybe this is related to something not installed or not configured in your machine... (This system has: x11proto-gl-dev, freeglut3, freeglut3-dev, libxft2, libxft2-dev, libgl1-mesa-{dev,dri,glx} among others that I don't know whether relevant or not! ;). BTW, I'm testing on a fast machine. It will be interesting to see what the old one produces. > [Johannes wrote] > Mouse wheel is a matter of binding. Place your mouse pointer over the > scroll bar and use the mouse wheel (it needs to be bound to the viewport). > > It is slow, because the default linesize (the amount a scrollbar > scrolls when pushing on the arrow is 1. I could change that, but > what would be a reasonable value? The height of a word in normal text (i.e. line height). We know the font and font factor from dillorc2 (or defaults). This number is a good candidate. ---------------- Side Note to all: Have you right-clicked over the search button? :-) -- Cheers Jorge.-

Oct. 11, 2007

Re: character entity references produce garbage

by Johannes.Hofmann＠gmx.de

On Wed, Oct 10, 2007 at 08:02:13AM +0200, Matthias Franz wrote: > On Tue, Oct 09, 2007 at 11:08:21PM +0200, Johannes Hofmann wrote: > > I can now reproduce this on a debian system without libxft-dev > > installed. > > Do you still see this after installing libxft-dev? > > No. Now it's gone, even if I comment out "freetype" and "type1" > in my xorg.conf. (I understand that Xft has something to do > with font rasterizing.) But it should work without Xft as well, > shouldn't it? Well, probabely. But this is an issue of fltk2 not of dillo. You will see these artefacts in the fltk test programs in the test/ directory of the fltk2 tarball too.

Oct. 10, 2007

Re: character entity references produce garbage

by matthias.franz＠ujf-grenoble.fr

On Tue, Oct 09, 2007 at 11:08:21PM +0200, Johannes Hofmann wrote: > I can now reproduce this on a debian system without libxft-dev > installed. > Do you still see this after installing libxft-dev? No. Now it's gone, even if I comment out "freetype" and "type1" in my xorg.conf. (I understand that Xft has something to do with font rasterizing.) But it should work without Xft as well, shouldn't it? -- Matthias Franz

Oct. 10, 2007

Re: [Dillo-dev] Re: [patch] improve scroll performance of dillo-fltk

by place

On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote: > On Mon, Oct 08, 2007 at 10:23:22PM +0200, Matthias Franz wrote: > > It is slow, because the default linesize (the amount a scrollbar > > scrolls when pushing on the arrow is 1. I could change that, but > > what would be a reasonable value? > > Apart from that it should not consume all CPU time. It doesn't > > here. On which html page do you test? > > It occurs on any page where you can scroll. Speaking of scrolling, if I hold down PageDown or PageUp, a large page of text often can't keep up. The scrollbar will be, say, at the extreme bottom, but the text might stop around the 80% mark. > Today I noticed that other features of dillo-fltk are also slower > than before. For example, I get approximately a 50% CPU load just > by moving the pointer repeatedly back and forth over a link so > that the pointer constantly changes from the "arrow" shape to the > "hand" shape and back. When I do this with the old dillo the CPU > load remains around zero. (I have an AMD Athlon prcessor running > at 660 MHz.) I don't know whether this is a problem with dillo, > fltk or just with my machine (Debian Etch). > > Do other people observe this problem as well? Now that I know to look for it, yes. It seems to depend on how large the textblock is that I move over. Commenting out Textblock::motionNotifyImpl() made no difference, and I don't know the upstream code well enough yet to chase down the problem efficiently...

Oct. 9, 2007

Re: [patch] improve scroll performance of dillo-fltk

by Matthias Franz

On Tue, Oct 09, 2007 at 08:09:48PM +0200, Johannes Hofmann wrote: > On Tue, Oct 09, 2007 at 07:29:46PM +0200, Matthias Franz wrote: > > On Tue, Oct 09, 2007 at 05:25:09PM +0200, Johannes Hofmann wrote: > > > Does it also happen, when you keep the arrow on the scrollbar > > > pressed? > > > > Yes. It happens as well when you move the scrollbar with the mouse > > (while pressing the left mouse button). > > Here it gets down to 10% idle when keeping the arrow pressed with > vanilla dillo-fltk. > With my patch it stays at 99% idle. > It might have to do with your X11 installation or Xft configuration. > Do you see antialiased fonts? I didn't have the development files for Xft installed!!! I've installed them, and now dillo-fltk uses antialiased fonts. The problem still remains, though. Heavy CPU load for scrolling or just moving the pointer across links. No difference between vanilla dillo-fltk and the patched version. Massive difference to the old dillo. -- Matthias Franz

Oct. 9, 2007

Re: character entity references produce garbage

by Matthias Franz

On Tue, Oct 09, 2007 at 09:10:09PM +0200, Johannes Hofmann wrote: > I don't see any artefacts here. I see dotted squares (which I guess means undefined characters); sometimes also other, random-looking characters come up. Looks like an off-by-one error. > Are you sure you compiled against the fltk2-tarball that Jorge > provided and not against some previously installed one? Well, pretty much. I've deleted an older version, and after linking dillo-fltk the access times of the files /usr/local/lib/libfltk2.a and /usr/local/lib/libfltk2_images.a (which have the same length as the ones in fltk-2.0.x-r5917/lib) change. -- Matthias Franz

Oct. 9, 2007

Re: [Dillo-dev] character entity references produce garbage

by Johannes Hofmann

Hi, On Tue, Oct 09, 2007 at 09:04:39PM +0200, Matthias Franz wrote: > Hi, > > I've observed that in dillo-fltk character entity references produce > garbage after the word they are contained in. Here is an example: > > <html> > <title>character entity references produce garbage</title> > no artefact > > one ärtefact > > two ärtéfacts > > three ärtéfâcts > </html> I don't see any artefacts here. Are you sure you compiled against the fltk2-tarball that Jorge provided and not against some previously installed one? > > Since I'm currently very busy with other (less interesting, but more > important) things, so I can only contribute to Dillo by reporting bugs > and testing solutions right now. I hope that this will change sometime > so that I can again write patches myself. Testing is very welcome as well! Johannes > > Cheers, > -- > Matthias Franz > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 9, 2007

character entity references produce garbage

by Matthias Franz

Hi, I've observed that in dillo-fltk character entity references produce garbage after the word they are contained in. Here is an example: <html> <title>character entity references produce garbage</title> no artefact one ärtefact two ärtéfacts three ärtéfâcts </html> Since I'm currently very busy with other (less interesting, but more important) things, so I can only contribute to Dillo by reporting bugs and testing solutions right now. I hope that this will change sometime so that I can again write patches myself. Cheers, -- Matthias Franz

Oct. 9, 2007