- Dillo-dev - lists.mailman3.com

New CVS repository and patches

by hans＠stare.cz

A few small build questions: > dcvs co dillo2 > dcvs co dw2 OK > cp -r dillo2 dillo2-cur > cp -r dw2 dw2-cur Why do I need to have a complete copy of a directory I just checked out? > ln -s dw2-cur dw-testbed Why do I need another name for that copy? Is it hardwired somewhere? > find dw2-cur -name CVS -exec rm \{\} \; > find dillo2-cur -name CVS -exec rm \{\} \; Why do I need to remove the CVS directories from the source tree? Do they stand in the way of something building properly? Isn't this equiavalent to doing 'cvs export' instead, anyway? > cd dw2-cur > ./autogen.sh > make Do I also need to somehow 'install' this? Because how is the dillo2 src gonna find it otherwise? > cd ../dillo2-cur > ./autogen.sh > make Thanks Jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

On Oct 16 18:13:29, Jan Stary wrote: > > > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > > Great, but it keeps asking for a password, am I missing something? > > Just press ENTER! > > Just asks for password again ... OTOH, -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo works just fine jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

> > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > Great, but it keeps asking for a password, am I missing something? > Just press ENTER! Just asks for password again ... Jan

Oct. 16, 2007

Re: character entity references produce garbage

by matthias.franz＠ujf-grenoble.fr

On Mon, Oct 15, 2007 at 05:58:38PM +0200, Johannes Hofmann wrote: > can you please try the little patch against fltk below. It should > fix the issue with --disable-xft and should not harm in case that > xft is enabled. works! Thanks! -- Matthias Franz

Oct. 15, 2007

Re: character entity references produce garbage

by Johannes.Hofmann＠gmx.de

Hi Matthias, can you please try the little patch against fltk below. It should fix the issue with --disable-xft and should not harm in case that xft is enabled. If it works for you I will send it to the fltk mailling list. Johannes --- src/x11/Font_xlfd.cxx.orig 2007-10-15 17:43:16 +0200 +++ src/x11/Font_xlfd.cxx 2007-10-15 17:43:53 +0200 @@ -432,7 +432,7 @@ void fltk::drawtext_transformed(const ch #if !X_UTF8_FONT XDrawString16(xdisplay, xwindow, gc, int(floorf(x+.5f)), - int(floorf(y+.5f)), buffer, n); + int(floorf(y+.5f)), buffer, count); #else #ifdef FONT_DEBUG //printf("current = %s\n", current->name);

Oct. 15, 2007

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

by bogus＠does.not.exist.com

Hi On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote: > Hi Sebastian, > > first of all thanks for your great work! > > On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > > Hi, > > > > On Mon, Oct 08, Matthias Franz 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. > > > > Just to save your time for investigating this further: This is a > > known problem. Generally, the GTK-based dillo drew only the part of > > the viewport, which was really needed, e.g. > > > > - scrolling was optimized, by copying one part, and redrawing only > > the formerly invisibly part (IIRC, this was done mostly by > > GTKLayout), > > This is already implemented in dillo-fltk from cvs. > But gtk1 seems to use an even faster approach. I think they use > XMoveWindow() instead of XCopyArea() for most part of the window, > which seems to be faster especially on some older machines. You can try FLTK2-r5941 (weekly stable). With that version we can ask in fltk-dev for details. -- Cheers Jorge.-

Oct. 14, 2007

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

by Johannes.Hofmann＠gmx.de

Hi Sebastian, first of all thanks for your great work! On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > Hi, > > On Mon, Oct 08, Matthias Franz 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. > > Just to save your time for investigating this further: This is a > known problem. Generally, the GTK-based dillo drew only the part of > the viewport, which was really needed, e.g. > > - scrolling was optimized, by copying one part, and redrawing only > the formerly invisibly part (IIRC, this was done mostly by > GTKLayout), This is already implemented in dillo-fltk from cvs. But gtk1 seems to use an even faster approach. I think they use XMoveWindow() instead of XCopyArea() for most part of the window, which seems to be faster especially on some older machines. Johannes

Oct. 14, 2007

New CVS and newwest FLTK2 release

by bogus＠does.not.exist.com

Hi there, I just updated the CVS so it can use the latest stable FLTK2. Get FLTK2 from www.fltk.org (r5941), or from here: wget http://www.dillo.org/dillo2/fltk-2.0.x-r5941.tar.bz2 You'll have to configure, compile and install this new version, and to rebuild the whole dw2 and dillo2. That way we stay more current. -- Cheers Jorge.-

Oct. 14, 2007

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

by sgeerken＠dillo.org

Hi, On Mon, Oct 08, Matthias Franz 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. Just to save your time for investigating this further: This is a known problem. Generally, the GTK-based dillo drew only the part of the viewport, which was really needed, e.g. - scrolling was optimized, by copying one part, and redrawing only the formerly invisibly part (IIRC, this was done mostly by GTKLayout), - small redraw requests (changing the color of a link, drawing one line of an image ...) resulted in drawing of actually small areas, - etc. This is not yet implemented in FLTK, due to the worse support by FLTK, which seems only to support redrawing of whole widgets. (And from the view of FLTK, the viewport is simply one FLTK widget.) For this reason, any redraw request results in redrawing the whole viewport area, which is of course horribly inefficient. In the documentation, there is a list of known problems with FLTK, available at dw-testbed-0.0.47/html/fltk-problems.html (after running doxygen). Anyone, which is a bit familiar with this, is invited to investigate this problem (and the other ones) further. (The "core" of Dw is already prepared, it is just a problem of connecting it to the FLTK-specific code.) When I'm just at it: > 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?) Scrolling is completely done by Dw (or, the FLTK part of Dw), so it is, as Johannes already mentioned, missing code. I do not know how scrolling wheel events are handled, but once this problem is solved, it should be simple to add. Sebastian

Oct. 14, 2007

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

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Oct 13, 2007 at 07:58:41PM +0200, Matthias Franz wrote: > Hi, > > I've started comparing the xtraces of dillo1 and dillo2 during scrolling > a long, _empty_ page (just 100 times "<br>"). > > The dillo2 trace contains the request > > 000:<:0392: 28: Request(62): CopyArea src-drawable=0x00a0000a dst-drawable=0x00a0000a gc=0x00a0000b src-x=0 src-y=74 dst-x=0 dst-y=73 width=1009 height=631 > > (A similar line appears in the previous traces of Johannes and mine.) > > For dillo1, I get > > 000:<:05b6: 28: Request(62): CopyArea src-drawable=0x00a00087 dst-drawable=0x00a0006d gc=0x00a00008 src-x=0 src-y=645 dst-x=0 dst-y=645 width=990 height=10 > > I don't have a detailed understanding of what's going on, but I find the > difference in the "height" parameter remarkable. It seems that dillo2 > copies an area - roughly the whole screen - which is 60 (!) times larger > than that copied by dillo1. 60 could also be the performance difference > we observe. That's interesting. dillo2 (with patch) scrolls by copying the screen content that was visible before scrolling and still is after scrolling. So the large CopyArea is expected. Then any freshly exposed area is redrawn from scratch. dillo1 / gtk1 seems to have a more optimized way of doing that, that does not need to copy that much of the screen. There is a link in the gtk code to this document: http://www.gtk.org/~otaylor/whitepapers/guffaw-scrolling.txt which might be related. Cheers, 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. 14, 2007