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

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

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

by matthias.franz＠ujf-grenoble.fr

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. Cheers, -- Matthias Franz

Oct. 13, 2007

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

by bogus＠does.not.exist.com

Hi, > > We should try to get rid of those artefacts for users that can't use > > xft. > > I agree. As Johannes has found out, this is an fltk bug. BTW, we should try FLTK2-r5941 before asking in FLTK-dev. I'll try that one ASAP. -- Cheers Jorge.-

Oct. 13, 2007

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

by bogus＠does.not.exist.com

On Sat, Oct 13, 2007 at 05:04:19PM +0200, Matthias Franz wrote: > On Fri, Oct 12, 2007 at 10:28:38PM +0200, Johannes Hofmann wrote: > > > So could it be that it has to do with RENDER and that most of you > > > have decent hadware acceleration for that? > > > > Yes, I guess that's the reason. You can compile fltk with the > > --disable-xft flag. In this case you will get the artefacts you > > mentioned before, but the performance should be similar to > > dillo1. > > I've compiled fltk with "--disable-xft". Now it doesn't use RENDER > any more (checked with xtrace). But I don't notice any performance > difference to dillo2 with xft. In particular, performance is far > from being that of dillo1. So, xft / RENDER does not seem to be the > reason. Maybe a detailed comparison of the xtrace logs of dillo1 and > dillo2-noxft could help? I've seen that dillo2 uses many "ChangeGC", > "SetClipRectangles" and "PolyFillRectangle" requests, which are not > used by dillo1. I don't know which requests are particularly expensive. AFAIR, dillo2 was passing trough the whole widget tree instead of just the to-be-rendered part. We were testing with Sebastian and optimizations were postponed. I also see a huge difference between dillo1 and dillo2. When Sebastian gets some free time he'll probably comment on that issue. If a simple but long FLTK2 widget can be scrolled with the same technique as in dillo2, with the same performance (or close) to dillo1, we'd know it is a bug within dw2. If not, we may ask in FKTK-dev. BTW, I preferred to take patches for dw2 and to commit them to CVS instead of pushing them for Sebastian to examine. That way he can catch up later while the patches improve. -- Cheers Jorge.-

Oct. 13, 2007

Fwd: Re: [Dillo-dev] New CVS directions page

by bogus＠does.not.exist.com

On Sat, Oct 13, 2007 at 06:40:11PM +0200, Justus Winter wrote: > On Fri, 12 Oct 2007 17:41:41 -0400, dillo-dev-bounces(a)dillo.org wrote: > > Please let me know if this time the directions work! :-P > > I would suggest the following changes: > > - find dw2-cur -name CVS -exec rm \{\} \; > - find dillo2-cur -name CVS -exec rm \{\} \; > + find dw2-cur dillo2-cur -name CVS | xargs rm -R > - cd dw2-cur; ./autogen.sh; ./configure; make > + cd dw2-cur; ./autogen.sh && ./configure && make > cd .. > - cd dillo2-cur; ./autogen.sh; ./configure; make > + cd dillo2-cur; ./autogen.sh && ./configure && make Done. -- Cheers Jorge.-

Oct. 13, 2007

Fwd: Re: [Dillo-dev] New CVS directions page

by 4winter＠informatik.uni-hamburg.de

On Fri, 12 Oct 2007 17:41:41 -0400, dillo-dev-bounces(a)dillo.org wrote: > Please let me know if this time the directions work! :-P I would suggest the following changes: - find dw2-cur -name CVS -exec rm \{\} \; - find dillo2-cur -name CVS -exec rm \{\} \; + find dw2-cur dillo2-cur -name CVS | xargs rm -R - cd dw2-cur; ./autogen.sh; ./configure; make + cd dw2-cur; ./autogen.sh && ./configure && make cd .. - cd dillo2-cur; ./autogen.sh; ./configure; make + cd dillo2-cur; ./autogen.sh && ./configure && make Hummel Hummel, Justus

Oct. 13, 2007

New CVS repository and patches

by matthias.franz＠ujf-grenoble.fr

On Thu, Oct 11, 2007 at 03:22:50PM -0400, dillo-dev-bounces(a)dillo.org wrote: > > [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. I need to say "--x-includes=/usr/include/X11/ --x-libraries=/usr/lib/" because I don't have the include file "X11/Intrinsic.h" from the Debian package libxt-dev, which is not installed. This package seems to be necessary to determine these directories automatically. When compiling glpuzzle, I get Compiling glpuzzle.cxx... In file included from ../fltk/glut.h:49, from glpuzzle.cxx:35: ../fltk/gl.h:69:21: error: GL/gl.h: No such file or directory glpuzzle.cxx:39:40: error: GL/glu.h: No such file or directory [many more errors] My config.h says /* Set this to 0 if your system does not have OpenGL. This will disable all the code in libfltk2_gl and disable the demo programs that use OpenGL. */ #define HAVE_GL 0 It seems that this flag is not evaluated when compiling glpuzzle. This should probably be changed by the fltk folks. Cheers, -- Matthias Franz

Oct. 13, 2007

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

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 12, 2007 at 10:28:38PM +0200, Johannes Hofmann wrote: > > So could it be that it has to do with RENDER and that most of you > > have decent hadware acceleration for that? > > Yes, I guess that's the reason. You can compile fltk with the > --disable-xft flag. In this case you will get the artefacts you > mentioned before, but the performance should be similar to > dillo1. I've compiled fltk with "--disable-xft". Now it doesn't use RENDER any more (checked with xtrace). But I don't notice any performance difference to dillo2 with xft. In particular, performance is far from being that of dillo1. So, xft / RENDER does not seem to be the reason. Maybe a detailed comparison of the xtrace logs of dillo1 and dillo2-noxft could help? I've seen that dillo2 uses many "ChangeGC", "SetClipRectangles" and "PolyFillRectangle" requests, which are not used by dillo1. I don't know which requests are particularly expensive. > We should try to get rid of those artefacts for users that can't use > xft. I agree. As Johannes has found out, this is an fltk bug. Cheers, -- Matthias Franz

Oct. 13, 2007

New CVS directions page

by bogus＠does.not.exist.com

On Fri, Oct 12, 2007 at 08:22:26PM +0200, Matthias Franz wrote: > PS: I have to specify the cvs repository as given on the dillo web page, > namely "-d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo". > The empty password does not work for jcid(a)auriga.wearlab.de. (This is > probably not surprising.) Sorry, I just updated the CVS page: http://www.dillo.org/cvs.html Please let me know if this time the directions work! :-P -- Cheers Jorge.-

Oct. 12, 2007