- Dillo-dev - lists.mailman3.com

Re: Accept-Encoding: gzip

by jcid＠dillo.org

Hi, On Mon, Nov 05, 2007 at 10:46:09PM +0000, place wrote: > What would you think of something like the code I have attached? I'd like to have gzip decoding in dillo2. > I had looked at the gzip portion of the i18n patch, just intending to put it > in my own copy, but it was unsatisfactory in some ways, so I ended up > changing the whole thing and this was the result. It looks quite advanced and that giving it a second pass on simplicity/elegance it'd be ready. > > Bad: 1. I stuck an awful lot of things into CacheEntry_t. Yes. IMO, having only: Dstr *EncodedData; char *Encoding; added to CacheEntry_t is cleaner. (we can add a Dstr_get_size() if necessary). > 2. During the downloading/decoding process, there is Data and > DecodedData. It gets fixed up afterward, but it means that things like > trying to view source during downloading does not work. I imagine the > fix being something like changing Data to RawData, DecodedData to Data, > freeing RawData after download is complete, and looking at all of the > current references to Data to figure out which of those they should > use. But I'll leave that for after I find out what you think of what I > have so far. From a design point of view, I'd prefer the decoding functions in a separate source file, that way, new decoders may be added easily and decoding complexity gets out of the cache part (the decoding internal state moves from the Cache entry to the decoding module, and decoding functions can be reused or extended). If we think of decoding as one part in a pipeline, null-decoding is what we have now, and gzip-decoding what we'd make for gzip. That way we can keep only one path for the data stream, and null-decode or gzip-decode into 'Data' when we need it. This solves the problem of using 'Data' while decoding naturally, because it is perceived as it always was (new-bytes from a stream), the only difference being they now come pushed from a decoder instead of the net (quite transparent). > Good: 1. Faster! > > 2. Faster! Yes. I can't wait to try it under a telephone line modem next week. :-) BTW, do you plan to make the linkblock/callback patch for html.cc (analog to plain.cc) or do you prefer me to work on it? -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

Hi Johannes, On Tue, Nov 06, 2007 at 08:51:15PM +0100, Johannes Hofmann wrote: > Hi, > > here is a patch to avoid the flickering even with > clear_double_buffer() as currently in CVS. It uses a self-made > double buffering for those drawing operations that need it (as it was > done in dillo1). The main advantage over generally switching on > double buffering, is that we need only one buffer for all > windows, which saves X-server side memory and avoids slowdowns with > many open windows. Yes, and it works much better than what we have now... > However this approach has some drawbacks: > > * The newly introduced FltkOffscreen class contains X11 specific > code and it would be better if this could be done by fltk. > But unfortunately there is an open bug > (http://www.fltk.org/str.php?L1042) Yes. One of the main advanteges of relying completely on fltk2 for drawing is that porting fltk2 to a new backend, makes dillo2 automatically work there too. Some people long for OpenGl, others the framebuffer, etc. > * When you compile fltk with the --disable-xft option you now need > to do "export CPPFLAGS=-DNO_XFT" before configuring dw-testbed. `fltk2-config --ldflags` reports on "-lXft". Maybe it can be used in configure.in as a test and thus, set CPPFLAGS automatically. > * It makes the redraws invisible again, which we might want to > reduce by other means. Yes, this is the key point. The main reason of leaving double buffering out is to remember that drawing needs an urgent fix. The number of redraws is not acceptable, and double buffering conceals it. I understand the need to reduce the annoying flickering, and huge memory footprint, but hesitate to commit the patch as is because it could stop people from porting fltk2 to a new backend when they need a browser. If you can add it as a compile time option (e.g. --with-internal-buffering) and automate the CPPFLAGS setting from configure, I'd commit. Now, what I'd really like is to reduce the number of redraws (an ugly bug) and to have an fltk2 means to make calls to X11. If you can work on the first task, it's more than welcomed. For the second one we need to coordinate with the fltk2 team. What do you think of this? > > Jorge, regardless of whether you want to apply this patch, could you > please apply the > > @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect > { > /** \bug Inefficient */ > > - push_clip( > - translateCanvasXToViewX (area->x), > - translateCanvasYToViewY (area->y), > - area->width, > - area->height); > - > redraw (DAMAGE_EXPOSE); > - > - pop_clip(); > } > > > part, which removes some calls added with my initial scrolling > patch. These calls are just wrong. push_clip/pop_clip can only be > called from within the draw() method. Out of place push/pop pair removal, commited. -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi, here is a patch to avoid the flickering even with clear_double_buffer() as currently in CVS. It uses a self-made double buffering for those drawing operations that need it (as it was done in dillo1). The main advantage over generally switching on double buffering, is that we need only one buffer for all windows, which saves X-server side memory and avoids slowdowns with many open windows. However this approach has some drawbacks: * The newly introduced FltkOffscreen class contains X11 specific code and it would be better if this could be done by fltk. But unfortunately there is an open bug (http://www.fltk.org/str.php?L1042) * When you compile fltk with the --disable-xft option you now need to do "export CPPFLAGS=-DNO_XFT" before configuring dw-testbed. * It makes the redraws invisible again, which we might want to reduce by other means. Jorge, regardless of whether you want to apply this patch, could you please apply the @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect { /** \bug Inefficient */ - push_clip( - translateCanvasXToViewX (area->x), - translateCanvasYToViewY (area->y), - area->width, - area->height); - redraw (DAMAGE_EXPOSE); - - pop_clip(); } part, which removes some calls added with my initial scrolling patch. These calls are just wrong. push_clip/pop_clip can only be called from within the draw() method. Regards, Johannes diff --git a/dw/Makefile.am b/dw/Makefile.am --- a/dw/Makefile.am +++ b/dw/Makefile.am @@ -45,7 +45,9 @@ libDw_fltk_a_SOURCES = \ fltkviewbase.cc \ fltkviewbase.hh \ fltkviewport.cc \ - fltkviewport.hh + fltkviewport.hh \ + fltkoffscreen.cc \ + fltkoffscreen.hh libDw_fltk_a_CXXFLAGS = @LIBFLTK_CXXFLAGS@ diff --git a/dw/fltkoffscreen.cc b/dw/fltkoffscreen.cc new file mode 100644 --- /dev/null +++ b/dw/fltkoffscreen.cc @@ -0,0 +1,104 @@ +/* + * Dillo Widget + * + * Copyright 2005-2007 Sebastian Geerken <sgeerken(a)dillo.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + + +#include <fltk/x11.h> + +#ifndef NO_XFT +#include <X11/Xft/Xft.h> +#endif + + +#include "fltkoffscreen.hh" + +using namespace fltk; + +namespace dw { +namespace fltk { + +FltkOffscreen::FltkOffscreen () { + w = 0; + h = 0; + pixmap = 0; + this->xftc = NULL; +} + + +FltkOffscreen::~FltkOffscreen () { + if (pixmap) { + XFreePixmap(xdisplay, pixmap); + } +#ifndef NO_XFT + if (this->xftc) { + XftDrawDestroy((XftDraw*) this->xftc); + } +#endif +} + + +void FltkOffscreen::begin (int w, int h) { + gsave = new GSave(); + + if (!pixmap || w > this->w || h > this->h) { + if (pixmap) { + XFreePixmap (xdisplay, pixmap); + } + pixmap = XCreatePixmap (xdisplay, xwindow, w, h, xvisual->depth); + +#ifndef NO_XFT + if (!this->xftc) { + this->xftc = XftDrawCreate(xdisplay, pixmap, + xvisual->visual, xcolormap); + } else { + XftDrawChange ((XftDraw*) this->xftc, pixmap); + } +#endif + + this->w = w; + this->h = h; + } + + saveWindow = xwindow; + xwindow = pixmap; +#ifndef NO_XFT + saveXftc = ::fltk::xftc; + ::fltk::xftc = (XftDraw*) this->xftc; +#endif + push_no_clip(); +} + + +void FltkOffscreen::end () { + pop_clip(); + xwindow = saveWindow; +#ifndef NO_XFT + ::fltk::xftc = (XftDraw*) saveXftc; +#endif + delete gsave; +} + + +void FltkOffscreen::draw (const ::fltk::Rectangle &area, int srcx, int srcy) { + XCopyArea(xdisplay, pixmap, xwindow, gc, srcx, srcy, + area.w(), area.h(), area.x(), area.y()); +} + +} // namespace fltk +} // namespace dw diff --git a/dw/fltkoffscreen.hh b/dw/fltkoffscreen.hh new file mode 100644 --- /dev/null +++ b/dw/fltkoffscreen.hh @@ -0,0 +1,34 @@ +#ifndef __DW_FLTKOFFSCREEN_HH__ +#define __DW_FLTKOFFSCREEN_HH__ + +#include <fltk/Rectangle.h> +#include <fltk/draw.h> + +namespace dw { +namespace fltk { + +class FltkOffscreen +{ +private: + int w; + int h; + unsigned long pixmap; + unsigned long saveWindow; + void *xftc; /* void* to avoid to include Xft/Xft.h */ + void *saveXftc; + ::fltk::GSave *gsave; + +public: + FltkOffscreen (); + ~FltkOffscreen (); + + void begin (int w, int h); + void end (); + void draw (const ::fltk::Rectangle &area, int srcx, int srcy); +}; + +} // namespace fltk +} // namespace dw + +#endif // __DW_FLTKOFFSCREEN_HH__ + diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -18,15 +18,12 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ - - #include "fltkviewport.hh" #include <fltk/draw.h> #include <fltk/damage.h> #include <fltk/events.h> #include <fltk/Cursor.h> - #include <stdio.h> using namespace fltk; @@ -36,12 +33,19 @@ namespace dw { namespace dw { namespace fltk { +FltkOffscreen *FltkViewBase::backBuffer; + FltkViewBase::FltkViewBase (int x, int y, int w, int h, const char *label): Group (x, y, w, h, label) { canvasWidth = 1; canvasHeight = 1; bgColor = WHITE; + + if (!backBuffer) { + backBuffer = new FltkOffscreen(); + } + } FltkViewBase::~FltkViewBase () @@ -50,14 +54,19 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { - Group::draw (); - + int d = damage(); ::fltk::Rectangle rect (x(), y(), w(), h()); /* fltk-clipping seems not to use widget coordinates */ ::fltk::intersect_with_clip(rect); rect.x(rect.x() - x()); rect.y(rect.y() - y()); + + if (!(d & DAMAGE_SCROLL)) { + backBuffer->begin(rect.w(), rect.h()); + + translate(-rect.x()-x() , -rect.y()-y() ); + } setcolor (bgColor); fillrect (rect); @@ -68,6 +77,11 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (!(d & DAMAGE_SCROLL)) { + backBuffer->end(); + backBuffer->draw(Rectangle(rect.x() + x(), rect.y() + y(), rect.w(), rect.h()), 0, 0); + } } core::ButtonState getDwButtonState () @@ -162,7 +176,7 @@ void FltkViewBase::setCanvasSize (int wi void FltkViewBase::setCursor (core::style::Cursor cursor) { - static Cursor *mapDwToFltk[] = { + static ::fltk::Cursor *mapDwToFltk[] = { CURSOR_CROSS, CURSOR_ARROW, CURSOR_HAND, @@ -225,15 +239,7 @@ void FltkViewBase::queueDraw (core::Rect { /** \bug Inefficient */ - push_clip( - translateCanvasXToViewX (area->x), - translateCanvasYToViewY (area->y), - area->width, - area->height); - redraw (DAMAGE_EXPOSE); - - pop_clip(); } void FltkViewBase::queueDrawTotal () diff --git a/dw/fltkviewbase.hh b/dw/fltkviewbase.hh --- a/dw/fltkviewbase.hh +++ b/dw/fltkviewbase.hh @@ -5,7 +5,7 @@ #include <fltk/Scrollbar.h> #include "fltkcore.hh" -#include "fltkcore.hh" +#include "fltkoffscreen.hh" namespace dw { namespace fltk { @@ -14,6 +14,7 @@ class FltkViewBase: public FltkView, pub { private: int bgColor; + static FltkOffscreen *backBuffer; protected: core::Layout *theLayout;

Nov. 6, 2007

"signal" name collision

by Johannes.Hofmann＠gmx.de

Hello, > > > [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. > I just looked into this issue once again and it seems that in principle the problem exists on Linux too. If you try to compile: #include <signal.h> namespace signal {} e.g. with "g++ -c namespace.cc", I get an error on Linux too. It's just that only DragonFly happens to (indirectly) include signal.h in the current dillo sources and Linux does not. So as soon as we need to include signal.h directly, we will have the problem on all platforms. I don't really understand the use of namespaces in the lout library. Instead of wrapping each class / feature in it's own namespace, I would have expected a single "lout" namespace containing classes like signal, container etc. This would also solve the name clash with signal.h. However Sebastian has certainly had his reasons for the current setup, so I don't want to make a patch for a drastic change like that without his comments. Regards, Johannes

Nov. 6, 2007

Crashes on OpenBSD

by jcid＠dillo.org

On Mon, Nov 05, 2007 at 05:51:17PM +0100, Johannes Hofmann wrote: > Ok, here is a patch that removes the LIBC5 special case and > uses getaddrinfo() also if --disable-threaded-dns is specified. > As far as I could see there were no real differences other than > logging between Dns_server() and Dns_blocking_server(), or am I > missing something? Commited. They're basically the same, but Dns_server runs in a thread and doesn't block the browser (with a max. of 4). The other blocks until the resolving function returns. It looks ok. -- Cheers Jorge.-

Nov. 5, 2007

dillo hogs during text selection

by matthias.franz＠ujf-grenoble.fr

Hi, I have observed that dillo2 may hog during text selection. For example, take the page http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . Go to some place in the table of contents, press the left mouse button and move the cursor around quickly so that the selected text changes all the time. After less a second, dillo becomes unresponsive and consumes all CPU time. This page also shows two additional issues: - There is no spacing between list items when the second item has less indentation than the first. (Look at the lines "mat - matrices" and "Types for affine ...".) - When the window size is increased, the vertical scroll bar suddenly disappears at a certain width and reappears below that width. (On my screen, this happens between 835 to 836 pixels.) In fact, the scroll bar is still there in the sense that line breaking leaves enough space for the bar. (I have reported this issue already before.) Cheers, -- Matthias Franz

Nov. 5, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Ok, here is a patch that removes the LIBC5 special case and uses getaddrinfo() also if --disable-threaded-dns is specified. As far as I could see there were no real differences other than logging between Dns_server() and Dns_blocking_server(), or am I missing something? Cheers, Johannes diff --git a/src/dns.c b/src/dns.c --- a/src/dns.c +++ b/src/dns.c @@ -39,11 +39,6 @@ * Uncomment the following line for debugging or gprof profiling. */ /* #undef D_DNS_THREADED */ - -/* - * Uncomment the following line for libc5 optimization - */ -/* #define LIBC5 */ /* Maximum dns resolving threads */ @@ -224,22 +219,8 @@ void a_Dns_init(void) /* * Allocate a host structure and add it to the list */ -static void Dns_note_hosts(Dlist *list, int af, struct hostent *host) -{ - int i; - if (host->h_length > DILLO_ADDR_MAX) - return; - for (i = 0; host->h_addr_list[i]; i++) { - DilloHost *dh = dNew0(DilloHost, 1); - dh->af = af; - dh->alen = host->h_length; - memcpy(&dh->data[0], host->h_addr_list[i], (size_t)host->h_length); - dList_append(list, dh); - } -} - -static void Dns_note_hosts2(Dlist *list, struct addrinfo *res0) +static void Dns_note_hosts(Dlist *list, struct addrinfo *res0) { struct addrinfo *res; DilloHost *dh; @@ -282,7 +263,6 @@ static void Dns_note_hosts2(Dlist *list, } } -#ifdef D_DNS_THREADED /* * Server function (runs on its own thread) */ @@ -314,7 +294,7 @@ static void *Dns_server(void *data) else if (h_errno == EAI_FAIL) MSG("DNS error: NO_RECOVERY\n"); } else { - Dns_note_hosts2(hosts, res0); + Dns_note_hosts(hosts, res0); dns_server[channel].status = 0; freeaddrinfo(res0); } @@ -334,67 +314,7 @@ static void *Dns_server(void *data) return NULL; /* (avoids a compiler warning) */ } -#endif -#ifndef D_DNS_THREADED -/* - * Blocking server-function (it doesn't use threads) - */ -static void Dns_blocking_server(void) -{ - int channel = 0; - struct hostent *host = NULL; - Dlist *hosts = dList_new(2); -#ifdef LIBC5 - int h_err; -#endif - - DEBUG_MSG(3, "Dns_blocking_server: starting...\n"); - DEBUG_MSG(3, "Dns_blocking_server: dns_server[%d].hostname = %s\n", - channel, dns_server[channel].hostname); - -#ifdef ENABLE_IPV6 - if (ipv6_enabled) { - host = gethostbyname2(dns_server[channel].hostname, AF_INET6); - if (host) { - Dns_note_hosts(hosts, AF_INET6, host); - } - } -#endif - -#ifdef LIBC5 - host = gethostbyname_r(dns_server[channel].hostname, &sh, buff, - sizeof(buff), &h_err); -#else - host = gethostbyname(dns_server[channel].hostname); -#endif - - if (!host) { -#ifdef LIBC5 - dns_server[channel].status = h_err; -#else - dns_server[channel].status = h_errno; -#endif - } else { - Dns_note_hosts(hosts, AF_INET, host); - } - if (dList_length(hosts) > 0) { - /* at least one entry on the list is ok */ - dns_server[channel].status = 0; - } else { - dList_free(hosts); - hosts = NULL; - } - - /* write IP to server data channel */ - DEBUG_MSG(3, "Dns_blocking_server: IP of %s is %p\n", - dns_server[channel].hostname, hosts); - dns_server[channel].addr_list = hosts; - dns_server[channel].ip_ready = TRUE; - - DEBUG_MSG(3, "Dns_blocking_server: leaving...\n"); -} -#endif /* * Request function (spawn a server and let it handle the request) @@ -426,7 +346,7 @@ static void Dns_server_req(int channel, pthread_create(&dns_server[channel].th1, &thrATTR, Dns_server, INT2VOIDP(dns_server[channel].channel)); #else - Dns_blocking_server(); + Dns_server(0); #endif }

Nov. 5, 2007

Crashes on OpenBSD

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Mon, Nov 05, 2007 at 12:38:16PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Sun, Nov 04, 2007 at 01:48:50PM +0100, Johannes Hofmann wrote: > > Hello, > > > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > > to use the inherently thread-safe getaddrinfo(3) interface that also has > > some other advantages (e.g. a predictable ordering of the returned > > addresses). > > Jorge, what do you think about this? Are there supported platforms > > that do not have getaddrinfo? Should we add a compile option for > > this? > > I gave it a look. > > AFAIS there're a few ways to do it. > > Considering that getaddrinfo is thread-safe by definition and also > inside POSIX, it's a good candidate. The gethostbyname* family is > thread-safe in glibc2, but who knows in other libraries. > > dns.c has too much #defines for my taste (yes, I wrote it! ;-), > and getting rid of the libc5 lines may also help simplicity. Exactly. > > I'd say, get the current CVS (patch applied), please also convert > Dns_blocking_server to getaddrinfo, and get rid of libc5 lines. > That way we end with a cleaner dns.c and will know for sure who still > may need the missing lines, because they can ask in dillo-dev. Ok, I will do that. I also think we should keep the Dns_blocking_server for now. > > OTOH, if we provide all the options at compile time, we may end > not knowing whether they're still used or not. Very true. Cheers, Johannes

Nov. 5, 2007

Crashes on OpenBSD

by jcid＠dillo.org

Hi Johannes, On Sun, Nov 04, 2007 at 01:48:50PM +0100, Johannes Hofmann wrote: > Hello, > > as I'm also using a BSD system, I converted the D_DNS_THREADED code > to use the inherently thread-safe getaddrinfo(3) interface that also has > some other advantages (e.g. a predictable ordering of the returned > addresses). > Jorge, what do you think about this? Are there supported platforms > that do not have getaddrinfo? Should we add a compile option for > this? I gave it a look. AFAIS there're a few ways to do it. Considering that getaddrinfo is thread-safe by definition and also inside POSIX, it's a good candidate. The gethostbyname* family is thread-safe in glibc2, but who knows in other libraries. dns.c has too much #defines for my taste (yes, I wrote it! ;-), and getting rid of the libc5 lines may also help simplicity. I'd say, get the current CVS (patch applied), please also convert Dns_blocking_server to getaddrinfo, and get rid of libc5 lines. That way we end with a cleaner dns.c and will know for sure who still may need the missing lines, because they can ask in dillo-dev. OTOH, if we provide all the options at compile time, we may end not knowing whether they're still used or not. -- Cheers Jorge.-

Nov. 5, 2007

Quick question about font_factor in dillorc2

by jcid＠dillo.org

On Mon, Nov 05, 2007 at 12:44:30PM +0000, Jeremy Henty wrote: > On Mon, Nov 05, 2007 at 09:28:25AM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 04, 2007 at 08:01:48AM +0000, Jeremy Henty wrote: > > > > Just out of interest, is there any reason why the default dillorc2 > > > sets font_factor to 1.5? > > > > Yes. It slipped out of my dillorc (I'm using a high resolution > > laptop). > > Ah, I wondered if that was it! > > > I think 1.2 is better, but hope the current 1.0 to bring comments! > > I think 1.0 is fine (1280 x 1024 desktop on a 17 inch monitor). It's > a little small, and I might increase font_factor if I started getting > eyestrain or the monitor was poorer quality. On a 1440x900 14 inch LCD, 1.5 is fine for me. It looks like 1.2 is a good default. -- Cheers Jorge.-

Nov. 5, 2007