June 2008 - Dillo-dev - lists.mailman3.com

what's next

by jcid＠dillo.org

On Mon, Jun 30, 2008 at 05:44:40PM +0200, Johannes Hofmann wrote: > Hi, > > for me dillo-fltk is pretty stable, fast, and generally a joy to use. > I still see the following issues: > > * In rare cases the screen contents is not properly redrawn due to > the redraw optimization. I'm looking for a way to reproduce it. > Anyone else seeing this? Not me. I'll pay more attention... > * The cursor is not always updated properly when over a link. This > happens while page is rendered and also when drag-scrolling with > the middle mouse button. > > * The bus error I had posted about is still there and I have seen it > once as a segafault with similar stack trace on a Linux box. I > still don't have a way to reproduce it though. Yeah, It'd be good to know what it is. > Any other problems or missing features? > > Jorge, what do you think about officially releasing what we have in > the near future? > Or do you prefer to wait for the big stuff (like CSS)? I'd like to release before CSS. I'll check the TABs stuff and see if it can be coded/included. Releasing by Aug looks OK to me. -- Cheers Jorge.-

June 30, 2008

Should --enable-ansi be removed?

by jcid＠dillo.org

On Sat, Jun 28, 2008 at 02:18:05AM +0000, corvid wrote: > I tried enabling it out of curiosity, and I see > that the code doesn't come close to compiling with it. > > Since it complains a lot about the various > MSG(...) macros > (warning: anonymous variadic macros were introduced in C99), > I'm guessing that the answer will be yes. Now that dillo needs a C++ compiler to build, I don't know whether this option is useful anymore. Does anybody know better? -- Cheers Jorge.-

June 30, 2008

what's next

by Johannes.Hofmann＠gmx.de

Hi, for me dillo-fltk is pretty stable, fast, and generally a joy to use. I still see the following issues: * In rare cases the screen contents is not properly redrawn due to the redraw optimization. I'm looking for a way to reproduce it. Anyone else seeing this? * The cursor is not always updated properly when over a link. This happens while page is rendered and also when drag-scrolling with the middle mouse button. * The bus error I had posted about is still there and I have seen it once as a segafault with similar stack trace on a Linux box. I still don't have a way to reproduce it though. Any other problems or missing features? Jorge, what do you think about officially releasing what we have in the near future? Or do you prefer to wait for the big stuff (like CSS)? Cheers, Johannes

June 30, 2008

Should --enable-ansi be removed?

by onepoint＠starurchin.org

On Sat, Jun 28, 2008 at 02:18:05AM +0000, corvid wrote: > Since it complains a lot about the various MSG(...) macros (warning: > anonymous variadic macros were introduced in C99), I tried to get -pedantic to work and I could silence those warnings in the C source by specifying -std=gnu99 but I could find no gcc 3.4.x option to do the same for C++ source. Maybe gcc 4.x has one? Regards, Jeremy Henty

June 28, 2008

Should --enable-ansi be removed?

by corvid＠lavabit.com

> I tried enabling it out of curiosity, and I see > that the code doesn't come close to compiling with it. > > Since it complains a lot about the various > MSG(...) macros > (warning: anonymous variadic macros were introduced in C99), > I'm guessing that the answer will be yes. To save any time spent discussing whether warnings with a rarely-used option can be ignored, I should mention that it also gave errors for, e.g., bitvec, apparently because a struct is returned. I can't imagine that we'd want to start changing around such things for the sake of this.

June 28, 2008

Should --enable-ansi be removed?

by corvid＠lavabit.com

I tried enabling it out of curiosity, and I see that the code doesn't come close to compiling with it. Since it complains a lot about the various MSG(...) macros (warning: anonymous variadic macros were introduced in C99), I'm guessing that the answer will be yes.

June 28, 2008

[patch] use prefs.vw_fontname

by jcid＠dillo.org

On Thu, Jun 26, 2008 at 09:54:07PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch uses prefs.vw_fontname instead of hardcoded > "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream > Charter" if it is not selected in dillorc. > This saves about 500k in initial startup size with --disable-xft > It hardly saves anything in the xft case. I don't know why. I would > have expected it the other way round.... Committed. -- Cheers Jorge.-

June 27, 2008

[patch] use prefs.vw_fontname

by jcid＠dillo.org

On Thu, Jun 26, 2008 at 09:54:07PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch uses prefs.vw_fontname instead of hardcoded > "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream > Charter" if it is not selected in dillorc. > This saves about 500k in initial startup size with --disable-xft > It hardly saves anything in the xft case. I don't know why. I would > have expected it the other way round.... IIRC, long ago Sebastian told me there was something strange with font handling (but at the time we had so many doubts...) -- Cheers Jorge.-

June 27, 2008

[patch] use prefs.vw_fontname

by Johannes.Hofmann＠gmx.de

Hi, attached patch uses prefs.vw_fontname instead of hardcoded "Bitstream Charter" in web.cc. Thereby it avoids opening "Bitstream Charter" if it is not selected in dillorc. This saves about 500k in initial startup size with --disable-xft It hardly saves anything in the xft case. I don't know why. I would have expected it the other way round.... Cheers, Johannes

June 26, 2008

Memory usage

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Jun 23, 2008 at 05:44:11PM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 22, 2008 at 10:11:30AM -0400, Jorge Arellano Cid wrote: > > ------------------------------------------- > > Huge page with different memory allocators: > > ------------------------------------------- > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.4 134912 113740 pts/17 S+ 18:56 0:02 ./dillo-fltk step: 2x > > 5.4 134916 113752 pts/17 S+ 18:57 0:02 ./dillo-fltk step: 2x > > 5.4 134828 113660 pts/17 S+ 18:58 0:02 ./dillo-fltk step: 2x > > > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > > > 5.1 117796 106436 pts/17 S+ 18:59 0:02 ./dillo-fltk step: cst > > 5.1 117568 106404 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > 5.1 117820 106460 pts/17 S+ 19:00 0:02 ./dillo-fltk step: cst > > > > > > This data comes from a memory usage reduction by tunning the > > simpleVector memory allocator. The first is the current one, > > which allocates in chunks of 2*numAlloc, the second allocates one > > by one and the third is a custom one I made. > > > > The 1-allocator is the best memory usage reducer but it's > > slower (roughly 20%). The cst-allocator reduces a bit less but is > > almost as fast as the 2x-allocator (2% slower or so). > > > > Memory reduction: > > > > VSZ RSS > > ----------------------------- > > 1-allocator 15% 7.3% > > cst-allocator 13% 6.5% > > ----------------------------- > > After some more study I got to a second cst2-allocator that reduces > almost as much as the 1-allocator but with the same (or better) speed > than the 2x one! > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 5.0 114940 105432 pts/17 S+ 18:53 0:02 ./dillo-fltk step: 1 > > 5.0 111976 105488 pts/17 S+ 18:54 0:03 ./dillo-fltk step: 1 > > 5.0 114872 105416 pts/17 S+ 18:54 0:02 ./dillo-fltk step: 1 > > 5.1 113224 105820 pts/17 S+ 13:57 0:02 ./dillo-fltk step: cst2 > 5.0 112948 105740 pts/17 S+ 13:58 0:02 ./dillo-fltk step: cst2 > 5.0 115528 105628 pts/17 S+ 13:59 0:02 ./dillo-fltk step: cst2 > > So now we have: > > ----------------------------- > Memory reduction: > > VSZ RSS > ----------------------------- > 1-allocator 15% 7.3% > cst-allocator 13% 6.5% > cst2-allocator 15% 7.3% > ----------------------------- > > > Committed. I have some concerns regarding the new SimpleVector implementation: * It introduces two arbitrary numbers (100 as a limit to switch to a different bahaviour, and the 1/10 factor) which are optimized for a specific page on a specific platform. The original 2x method feels more general to me even though it may be a bit less memory efficient. * It probabely only works fast, as most malloc libraries use some heuristics to avoid memcpy for every realloc. Depending on this behaviour may create problems on more exotic platforms. * Rather than igoring the initAlloc parameter I would propose to reconsider the places where SimpleVector() is inititalized with initAlloc > 1. There also is an interesting comment about initAlloc in the Textblock constructor. Having said all this, it's not a big issue for me. If CPU usage should really become a problem on some platform, we could easily change the code. It's just 2 or 3 lines after all. Cheers, Johannes

June 26, 2008