- Dillo-dev - lists.mailman3.com

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

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

by Johannes.Hofmann＠gmx.de

Hi Matthias, On Fri, Oct 12, 2007 at 09:26:57PM +0200, Matthias Franz wrote: > On Fri, Oct 12, 2007 at 07:59:34PM +0200, Johannes Hofmann wrote: > > 000:<:c47f: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=554 glyphs=0x5a,0x4b,0x48,0x51; }; > > Hi Johannes, > > two additonal observation: > > 1) I've had a look at the xtrace output of dillo1. It seems not to use > the RENDER extension (apart from two requests > > 000:<:0029: 12: RENDERRequest(151): RenderQueryVersion majorVersion=0 minorVersion=10 > 000:<:002a: 4: RENDERRequest(151): RenderQueryPictFormats > > at the beginning). > > 2) I've played around with 2D-acceleration and compared CPU load while > scrolling. Result: > > dillo1: XAA: excellent (almost no load), EXA: very bad (100%, delays) > dillo2: XAA: bad (100%) EXA: slightly better (75%) > > I've read that the EXA implementation of my Xorg server (7.1.1) is > very bad, at least for my video driver (savage). On the other hand, > RENDER support is said to be better in EXA than in XAA. > > 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. We should try to get rid of those artefacts for users that can't use xft. Cheers, Johannes

Oct. 12, 2007

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

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 12, 2007 at 07:59:34PM +0200, Johannes Hofmann wrote: > 000:<:c47f: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=554 glyphs=0x5a,0x4b,0x48,0x51; }; Hi Johannes, two additonal observation: 1) I've had a look at the xtrace output of dillo1. It seems not to use the RENDER extension (apart from two requests 000:<:0029: 12: RENDERRequest(151): RenderQueryVersion majorVersion=0 minorVersion=10 000:<:002a: 4: RENDERRequest(151): RenderQueryPictFormats at the beginning). 2) I've played around with 2D-acceleration and compared CPU load while scrolling. Result: dillo1: XAA: excellent (almost no load), EXA: very bad (100%, delays) dillo2: XAA: bad (100%) EXA: slightly better (75%) I've read that the EXA implementation of my Xorg server (7.1.1) is very bad, at least for my video driver (savage). On the other hand, RENDER support is said to be better in EXA than in XAA. So could it be that it has to do with RENDER and that most of you have decent hadware acceleration for that? Cheers, -- Matthias Franz

Oct. 12, 2007