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

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

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: > Could you try the same on your system, so that we find out, whether > the patch does not work for you or whether scrolling is still too > CPU consuming even with the working patch? Hi Johannes, here is my trace: 000:<:877c: 28: Request(62): CopyArea src-drawable=0x00800008 dst-drawable=0x00800008 gc=0x00800009 src-x=0 src-y=74 dst-x=0 dst-y=73 width=1009 height=631 000:>:877c: Event NoExposure(14) drawable=0x00800008 minor-opcode=0x0000 major-opcode=0x3e 000:<:877d: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x00800009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=704 w=1009 h=1}; 000:<:877e: 20: RENDERRequest(151): RenderSetPictureClipRectangles picture=0x00800057 xOrigin=0 yOrigin=0 rectangles={x=0 y=704 w=1009 h=1}; 000:<:877f: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x00800009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=704 w=1009 h=1}; 000:<:8780: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00e0e0e0} 000:<:8781: 20: Request(70): PolyFillRectangle drawable=0x00800008 gc=0x00800009 rectangles={x=0 y=0 w=1024 h=725}; 000:<:8782: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x00800009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=704 w=1009 h=1}; 000:<:8783: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00dcd1ba} 000:<:8784: 20: Request(70): PolyFillRectangle drawable=0x00800008 gc=0x00800009 rectangles={x=0 y=704 w=1009 h=1}; 000:<:8785: 44: RENDERRequest(151): RenderCompositeGlyphs8 op=Over(0x03) src=0x0080000f dst=0x00800057 maskFormat=0x00000024 glyphset=0x0080003a xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=711 glyphs=0x36,0x57,0x44,0x57,0x58,0x56; }; 000:<:8786: 40: RENDERRequest(151): RenderCompositeGlyphs8 op=Over(0x03) src=0x0080000f dst=0x00800057 maskFormat=0x00000024 glyphset=0x0080003a xSrc=0 ySrc=0 glyphcmds={deltax=65 deltay=711 glyphs=0x52,0x49; }; 000:<:8787: 40: RENDERRequest(151): RenderCompositeGlyphs8 op=Over(0x03) src=0x0080000f dst=0x00800057 maskFormat=0x00000024 glyphset=0x0080003a xSrc=0 ySrc=0 glyphcmds={deltax=88 deltay=711 glyphs=0x57,0x4b,0x4c,0x56; }; 000:<:8788: 44: RENDERRequest(151): RenderCompositeGlyphs8 op=Over(0x03) src=0x0080000f dst=0x00800057 maskFormat=0x00000024 glyphset=0x0080003a xSrc=0 ySrc=0 glyphcmds={deltax=125 deltay=711 glyphs=0x47,0x52,0x46,0x58,0x50,0x48,0x51,0x57; }; 000:<:8789: 20: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00000000 clip-mask=None(0x00000000)} 000:<:878a: 16: RENDERRequest(151): RenderChangePicture picture=0x00800057 mask=0x00000040 values={repeat=false(0x00)} 000:<:878b: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00ababab} 000:<:878c: 20: Request(70): PolyFillRectangle drawable=0x00800008 gc=0x00800009 rectangles={x=1009 y=88 w=15 h=602}; 000:<:878d: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00000000} 000:<:878e: 28: Request(66): PolySegment drawable=0x00800008 gc=0x00800009 segments={x1=1009 y1=102 x2=1023 y2=102},{x1=1023 y1=88 x2=1023 y2=101}; 000:<:878f: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00f9f9f9} 000:<:8790: 28: Request(66): PolySegment drawable=0x00800008 gc=0x00800009 segments={x1=1009 y1=88 x2=1022 y2=88},{x1=1009 y1=89 x2=1009 y2=101}; 000:<:8791: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00ababab} 000:<:8792: 28: Request(66): PolySegment drawable=0x00800008 gc=0x00800009 segments={x1=1010 y1=101 x2=1022 y2=101},{x1=1022 y1=89 x2=1022 y2=100}; 000:<:8793: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00e0e0e0} 000:<:8794: 20: Request(70): PolyFillRectangle drawable=0x00800008 gc=0x00800009 rectangles={x=1010 y=89 w=12 h=12}; 000:<:8795: 16: Request(128): unknown 000:<:8796: 16: Request(56): ChangeGC gc=0x00800009 values={foreground=0x00000000} Cheers, -- Matthias Franz

Oct. 12, 2007

two minor bugs

by matthias.franz＠ujf-grenoble.fr

Hi, here are two minor bugs: - If a page is too long to fit inside the dillo window, you get a scrollbar at the right border. Sometimes this scrollbar gets lost when you enlarge the window (by dragging the lower right corner or by clicking on the "full screen" button) although the page still doesn't fit. This seems to depend on the page and doesn't happen very often. For an example, try http://www-fourier.ujf-grenoble.fr/~franz/ . - When opening a new page or when moving through the history list, dillo remembers the screen position although positions on different pages should not be related. 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.) Cheers, -- Matthias Franz

Oct. 12, 2007

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

by Johannes.Hofmann＠gmx.de

Hi Matthias, I just made a xtrace (http://packages.debian.org/unstable/x11/xtrace) when scrolling the http://www.w3.org/TR/xslt page with patched dillo (result below). I think this is pretty good already. Just the newly exposed glyphs get rendered. Each word is sent to the X-Server seperately. This might be an area for improvement. Could you try the same on your system, so that we find out, whether the patch does not work for you or whether scrolling is still too CPU consuming even with the working patch? Here is what I did to get the trace: xtrace > /tmp/xtrace.out export DISPLAY=:9 dillo-fltk http://www.w3.org/TR/xslt Then scroll using the triangle of the scrollbar for a while and stop dillo. The resulting file is huge but I am only interested in the repeating sections that result from the scrolling and start with CopyArea. Gruss, Johannes 000:<:c474: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00000000} 000:<:c475: 28: Request(62): CopyArea src-drawable=0x01c00008 dst-drawable=0x01c00008 gc=0x01c00009 src-x=0 src-y=93 dst-x=0 dst-y=73 width=765 height=467 000:>:c475: Event NoExposure(14) drawable=0x01c00008 minor-opcode=0x0000 major-opcode=0x3e 000:<:c476: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c477: 20: RENDERRequest(154): RenderSetPictureClipRectangles picture=0x01c00036 xOrigin=0 yOrigin=0 rectangles={x=0 y=540 w=765 h=20}; 000:<:c478: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c479: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00e0e0e0} 000:<:c47a: 20: Request(70): PolyFillRectangle drawable=0x01c00008 gc=0x01c00009 rectangles={x=0 y=0 w=780 h=580}; 000:<:c47b: 20: Request(59): SetClipRectangles ordering=YXBanded(0x03) gc=0x01c00009 clip-x-origin=0 clip-y-origin=0 rectangles ={x=0 y=540 w=765 h=20}; 000:<:c47c: 16: Request(56): ChangeGC gc=0x01c00009 values={foreground=0x00dcd1ba} 000:<:c47d: 20: Request(70): PolyFillRectangle drawable=0x01c00008 gc=0x01c00009 rectangles={x=0 y=540 w=765 h=20}; 000:<:c47e: 60: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00063 xSrc=0 ySrc=0 glyphcmds={deltax=5 deltay=530 glyphs=0x1f,0x5b,0x56,0x4f,0x1d,0x44,0x5 3,0x53,0x4f,0x5c,0x10,0x57,0x48,0x50,0x53,0x4f,0x44,0x57,0x48,0x56,0x12,0x21; }; 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; }; 000:<:c480: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=38 deltay=554 glyphs=0x4c,0x57; }; 000:<:c481: 44: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=47 deltay=554 glyphs=0x5a,0x44,0x51,0x57,0x56; }; 000:<:c482: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=82 deltay=554 glyphs=0x57,0x52; }; 000:<:c483: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=95 deltay=554 glyphs=0x46,0x52,0x53,0x5c; }; 000:<:c484: 40: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=124 deltay=554 glyphs=0x57,0x4b,0x48; }; 000:<:c485: 44: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00063 xSrc=0 ySrc=0 glyphcmds={deltax=144 deltay=554 glyphs=0x5b,0x50,0x4f,0x1d,0x4f,0x44,0 x51,0x4a; }; 000:<:c486: 48: RENDERRequest(154): RenderCompositeGlyphs8 op=Over(0x03) src=0x01c0000f dst=0x01c00036 maskFormat=0x00000026 glyphset=0x01c00037 xSrc=0 ySrc=0 glyphcmds={deltax=203 deltay=554 glyphs=0x44,0x57,0x57,0x55,0x4c,0x45,0 x58,0x57,0x48,0x11; };

Oct. 12, 2007

fix for links within lists

by jcid＠dillo.org

Hi, On Mon, Oct 08, 2007 at 03:18:10PM +0000, place wrote: > BTW, are you still opposed to the idea of click-to-load-images? > I'm on dialup, so one of the first things I had to do was port > my old hacks from my gtk version. I am/was not opposed. I thought a good solution was to have a small tools icon (near bug meter) where you could toggle images on/off, my_colors on/off, wide_rendering on/off etc. Now, being in no-images mode and being able to request a single one instead of all at once looks like a good idea. Of course you'd also have the option of turning images on, and have all requested for that page. As most of the images don't specify a size, a place holder must be provided (as the broken image link in other browser). From there, a right click menu could offer to download that image only. > Also, do you have any thoughts on the proper solution for pages using > character sets that aren't utf-8 or a subset thereof? I made something > that reads the charset from Content-Type in the header or meta tags > and then, in Html->write, runs the buffers through iconv. (Pages are > mostly readable, but I think I'm either losing partial characters at > buffer boundaries or losing partial tags between Html->write_raw() > calls or something...) Basically that. It's not simple though. For instance an http page may specify the charset in Content-Type, but when saved not give any clue in its meta tags. Or have only meta but not Content-Type as served, or give no clue at all, etc. The main idea is to keep the page as is in the cache (so it can be saved verbatim) and to pass it trough a filter to make the conversion to utf-8 inside Dillo. If the iconv backpack adds too much to Dillo's size, the task can be delegated to a dpi, and a small subset with the main conversions be kept inside Dillo. -- Cheers Jorge.-

Oct. 12, 2007

fix for links within lists

by bogus＠does.not.exist.com

On Mon, Oct 08, 2007 at 09:08:57PM +0200, Matthias Franz wrote: > Dear all, > > first of all I want to express my gratitude to Jorge and Sebastian for > pushing Dillo forward despite the numerous difficulties. Thanks a lot!!! Thanks Matthias for these nice lines. -- Cheers Jorge.-

Oct. 12, 2007

New CVS repository and patches

by bogus＠does.not.exist.com

On Thu, Oct 11, 2007 at 10:45:08PM +0200, Frank Gevaerts wrote: > On Thu, Oct 11, 2007 at 03:22:50PM -0400, dillo-dev-bounces(a)dillo.org wrote: > > Hi There! > > > > Once again, thanks for the patches and keep them flowing. > > > > The new CVS repository is up and updated with the patches: > > Hi, > > The code in CVS doesn't compile as-is for me, due to my fltk2 not being > installed in /usr or /usr/local. I need the attached patch to make it > work. > > Frank Done! BTW, please send patches with "diff -pru". This is, let's say we have: dillo2 // CVS tree dillo2-cur // working tree dw2 // CVS tree dw2-cur // working tree diff -pru dillo2 dillo2-cur > <patch-name-dillo2>.diff diff -pru dw2 dw2-cur > <patch-name-dw2>.diff TIA. -- Cheers Jorge.-

Oct. 12, 2007

New CVS repository and patches

by bogus＠does.not.exist.com

On Thu, Oct 11, 2007 at 11:16:45PM +0200, Johannes Hofmann wrote: > > [...] > > 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? Just press ENTER! > > > [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. OK. > > > > [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. Good. Please read my comments in the next mail (after finishing this one). > > > [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. Good. > > ---------------- > > 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: Sorry I left that out, but now it is in CVS too. -- Cheers Jorge.-

Oct. 11, 2007

New CVS repository and patches

by lists＠gevaerts.be

On Thu, Oct 11, 2007 at 03:22:50PM -0400, dillo-dev-bounces(a)dillo.org wrote: > Hi There! > > Once again, thanks for the patches and keep them flowing. > > The new CVS repository is up and updated with the patches: Hi, The code in CVS doesn't compile as-is for me, due to my fltk2 not being installed in /usr or /usr/local. I need the attached patch to make it work. Frank -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

Oct. 11, 2007