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

Re: new browser windows slower than first one

by place＠gobigwest.com

Turning off double buffering means that the default code from the tree is unusably slow and annoying on my ancient(*) computer. This might dissuade someone who comes along at the wrong time intending to give the fltk dillo a look. Though admittedly it might be my configuration... * Computers never get slow; software gets slow!

Oct. 22, 2007

directory listings?

by bogus＠does.not.exist.com

Hi, On Mon, Oct 22, 2007 at 09:13:01AM +0200, Jan Stary wrote: > On Oct 19 19:33:56, dillo-dev-bounces(a)dillo.org wrote: > > On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > > > Hi all, > > > > > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > > > listing as it should. It's full of subdirectories, and they > > > are all the same (just contain JPEGs). > > > > > > Now when I click on _some_ of the links, I get a correct directory > > > listing again (of the subdirectory). When I click on _some_ others > > > I get nothing, just a blank page (gray). > > > > > > [...] > > > > Please try the CVS code on this. > > With current code, I cannot even test it, because > dillo keeps "Connecting to server" forever, > giving the following message: > > > $ dillo-fltk http://stare.cz/~hans/foto/ > prefs: Can't open dillorc2 file: /home/hans/.dillo/dillorc2 > prefs: Can't open dillorc2 file: /usr/local/etc/dillorc > prefs: Using internal defaults. > dillo_dns_init: Here we go! (threaded) > Enabling cookies as from cookiesrc... > Nav_open_url: Url=>http://stare.cz/~hans/foto/< > Dns_server [0]: stare.cz is 0x7f7b8640 > Connecting to 88.208.90.43 > ** ERROR **: IO_fd_write_cb: call on already closed io! > a_UIcmd_close_bw > > ... until I kill it. > > (The server is acessible, the same URL can be browsed with lynx.) Yes, that's a race condition I have to debug. Just try it several times (start browser close, try another). It will eventually succeed... -- Cheers Jorge.-

Oct. 22, 2007

directory listings?

by hans＠stare.cz

On Oct 19 19:33:56, dillo-dev-bounces(a)dillo.org wrote: > On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > > Hi all, > > > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > > listing as it should. It's full of subdirectories, and they > > are all the same (just contain JPEGs). > > > > Now when I click on _some_ of the links, I get a correct directory > > listing again (of the subdirectory). When I click on _some_ others > > I get nothing, just a blank page (gray). > > > > [...] > > Please try the CVS code on this. With current code, I cannot even test it, because dillo keeps "Connecting to server" forever, giving the following message: $ dillo-fltk http://stare.cz/~hans/foto/ prefs: Can't open dillorc2 file: /home/hans/.dillo/dillorc2 prefs: Can't open dillorc2 file: /usr/local/etc/dillorc prefs: Using internal defaults. dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: Url=>http://stare.cz/~hans/foto/< Dns_server [0]: stare.cz is 0x7f7b8640 Connecting to 88.208.90.43 ** ERROR **: IO_fd_write_cb: call on already closed io! a_UIcmd_close_bw ... until I kill it. (The server is acessible, the same URL can be browsed with lynx.) Jan

Oct. 22, 2007

Re: new browser windows slower than first one

by matthias.franz＠ujf-grenoble.fr

On Sun, Oct 21, 2007 at 03:35:49PM +0200, Johannes Hofmann wrote: > switches double-buffering off. This makes quite a difference for > scrolling here. Scrolling an empty page at fullscreen now consumes 1.5% CPU load and not 100% as before. Fantastic!!! If the page has content, it's considerably more (at least 20%), most likely because of the many unneccessary redraws. Cheers, -- Matthias Franz

Oct. 21, 2007

Re: new browser windows slower than first one

by bogus＠does.not.exist.com

Hi, On Sun, Oct 21, 2007 at 03:35:49PM +0200, Johannes Hofmann wrote: > On Sat, Oct 20, 2007 at 08:14:47PM +0200, Johannes Hofmann wrote: > > Hello, > > > > just noticed a scroll performance-related problem: > > When I create many browser windows (e.g. using the middle mouse > > button), srolling in these created windows causes more Xorg CPU > > usage than in the first one. > > Maybe, scrolling in the new windows causes redraws from the old > > ones? > > Argh, fltk2 uses double-buffering by default. This uses quite some > memory on the X-server side and slows things down. > > --- a/src/ui.cc Sat Oct 20 17:59:33 2007 +0200 > +++ b/src/ui.cc Sun Oct 21 14:47:49 2007 +0200 > @@ -580,6 +580,7 @@ UI::UI(int win_w, int win_h, const char* > { > int s_h = 20; > resizable(this); > + clear_double_buffer(); > begin(); > TopGroup = this; > > > switches double-buffering off. This makes quite a difference for > scrolling here. However during rendering there is some flicker now. > But the excessive redraws that cause the flicker should be > addressed anyhow. Commited! This is will be very good for debugging screen updates. Those not working in it can comment it out in src/ui.cc: + //clear_double_buffer(); -- Cheers Jorge.-

Oct. 21, 2007

drag scrolling as in good old dillo1

by bogus＠does.not.exist.com

On Sat, Oct 20, 2007 at 01:06:41PM +0200, Johannes Hofmann wrote: > Hi, > > here is a patch to enable drag scrolling with the middle mouse > button as in dillo1. Done. > For me from now only the "Backspace" hotkey is missing for daily > browsing - apart from the occasional crashes of course :-) :-) -- Cheers Jorge.-

Oct. 21, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

On Sat, Oct 20, 2007 at 08:14:47PM +0200, Johannes Hofmann wrote: > Hello, > > just noticed a scroll performance-related problem: > When I create many browser windows (e.g. using the middle mouse > button), srolling in these created windows causes more Xorg CPU > usage than in the first one. > Maybe, scrolling in the new windows causes redraws from the old > ones? Argh, fltk2 uses double-buffering by default. This uses quite some memory on the X-server side and slows things down. --- a/src/ui.cc Sat Oct 20 17:59:33 2007 +0200 +++ b/src/ui.cc Sun Oct 21 14:47:49 2007 +0200 @@ -580,6 +580,7 @@ UI::UI(int win_w, int win_h, const char* { int s_h = 20; resizable(this); + clear_double_buffer(); begin(); TopGroup = this; switches double-buffering off. This makes quite a difference for scrolling here. However during rendering there is some flicker now. But the excessive redraws that cause the flicker should be addressed anyhow. Johannes

Oct. 21, 2007

new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hello, just noticed a scroll performance-related problem: When I create many browser windows (e.g. using the middle mouse button), srolling in these created windows causes more Xorg CPU usage than in the first one. Maybe, scrolling in the new windows causes redraws from the old ones? Johannes

Oct. 20, 2007

Scrolling patch!

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 19, 2007 at 07:09:49PM -0300, dillo-dev-bounces(a)dillo.org wrote: > Here's a patch I wanted to add since a long time. Remembering > the scroll position in a page. At least for me, it improves web > browsing a lot! Hi Jorge, this patch is really helpful!!! Maybe this is a good time to remember a patch of mine that I sent to Jorge (not to dillo-dev) more than 2 years ago (for Dillo1, of course). It changed the way the scrolling position is remembered so that, I think, dillo becomes more user friendly. In Dillo[12], the scrolling position is associated to a URL. This means that when displaying a page which is already in the history list, the old position is restored (no matter whether one uses the same window or another). With the patch, there is a separate scrolling position for each item in the history list. This means that each click on a link opens a page at the beginning (or at the position specified by the tag if there is one). I find this natural and sometimes even important: Consider some manual on several web pages where a link takes you to the definition of some function etc. If you click on a link, you don't care if the definition you want to see is on a page where you have been before (or maybe even the same page); you just want to open the new page there where the relevant information is, and going one page back should bring you to the page where you clicked on the link (even if it is the same page). The patch, which was against dillo1 CVS from 2005-01-05, can be found at http://www-fourier.ujf-grenoble.fr/~franz/dillo/dillo-CVS20050105-history.d… It is quite long because it changed some data types which were used everywhere, but I would like to point out that the resulting binary was not bigger than before (rather on the contrary, if I remember correctly). Below I include the email to Jorge where I explain the patch. As I've already written in another email, I'm quite busy with other things right now. Maybe this patch is still useful for others. ===== from email to Jorge, 2005-01-06 ===== DETAILED DESCRIPTION #################### FIXED BUGS: * BUG#569: Links to the same page are not recorded in the history list. * BUG#581: Reloading an URL with fragment identifier doesn't keep the page position. * The scrolling positions of a page are initialised to 0 (new: -1). This way one cannot safely tell whether a page has already been displayed. Test: Load an URL with fragment identifier, move to the very top of the page, click back button, click forward button. Now you are again at the anchor position. * Jumping to an anchor position in Nav_open_url is premature: Try to open some non-existing URL with fragment identifier #anchor. Then Dillo jumps to #anchor on the current page (if such an anchor exists). * Some others that I'm to lazy to describe. (Changing settings before the new page has arrived, see below.) CHANGES: * The real changes (described below) happen in nav.[ch], url.[ch], a_Web_dispatch_by_type and Html_close. The files history.[ch] are removed (see below). * Look first a Nav_open_url, a_Nav_expect_done and a_Web_dispatch_by_type. Now a_Nav_expect_done is called for every page (it should better be called a_Nav_open_url_finish). I've moved many things from Nav_open_url and a_Web_dispatch_by_type to a_Nav_expect_done, either because the code was similar, or because many things should only be done when the new page has arrived, for example saving the scrolling position of the current page or clearing the page menu. * In Nav_open_url, the navigation index nav_stack_ptr is not changed any more; instead the new position is stored in nav_expect_ptr. The reason is that otherwise one cannot save the current scrolling position in a_Nav_expect_done, because one doesn't know any more what was the current page. * The scrolling position is not stored in DilloUrl anymore, but in the navigation list (or stack). The list items are now of the new type NavItem (browser.h): /* navigation list item */ typedef struct { DilloUrl *url; const gchar *title; gint posx; /* -1 if page has not been displayed */ gint posy; } NavItem; This is also the place where form data should be kept so that Dillo remembers the filled-in values in the history list. (This is another patch I'm planning.) * Before, the navigation list only kept indices to the history list (history.h): typedef struct { DilloUrl *url; gchar *title; } H_Item; * Global history list */ static H_Item *history = NULL; static gint history_size = 0; /* [1 based] */ static gint history_size_max = 16; This additional referencing from the navigation list to the history list seemed to me very weird. I guess the history list is still from a time where Dillo didn't support multiple browser windows. As you can see, I've completely removed the history list. Consequence: The files history.[ch] are completely REMOVED. * BUG#581 actually had two reasons. One was located in nav.c (now fixed as a by-product), the other was the following: Restoring a previous scrolling position in a_Web_dispatch_by_type doesn't always work because at that time the page is being rendered. If there one calls a_Dw_gtk_scrolled_window_set_scrolling_position with a position that doesn't fit on the page (because rendering hasn't reached that position yet), the call is ignored. Current patch: Restore the scrolling position after rendering has been finished in Html_close. This works, but it is not optimal. A better solution would be as for anchors: Anchor positions can be set even if the anchor place hasn't been rendered yet. But I think this should be done by a dw_* specialist. CODE STATUS: * The code seems to be stable. * PROBLEM: When going through the history list, it takes at lot of time before the new page is displayed. (Try a long page like the HTML 3.2 spec.) Before, switching was only done after some time (I think when the page was rendered), now the switching is immediately, which gives you a blank page for a fraction of a second before the new page content is displayed. This is particularly noticable when you change between two pages with different background colours. * There is still a small scrolling position problem: Sometimes when I come back to a previously displayed page (using back/forward), the scrolling position has changed somewhat (up to 1/3 of a screen). But this happens with the unpatched Dillo as well, so it seems to be a separate bug. * The code might still need a bit polishing. ===== end email ===== Cheers, -- Matthias Franz

Oct. 20, 2007

drag scrolling as in good old dillo1

by Johannes.Hofmann＠gmx.de

Hi, here is a patch to enable drag scrolling with the middle mouse button as in dillo1. For me from now only the "Backspace" hotkey is missing for daily browsing - apart from the occasional crashes of course :-) Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -47,6 +47,7 @@ FltkViewport::FltkViewport (int x, int y vscrollbar->callback (vscrollbarCallback, this); scrollX = scrollY = 0; + dragScrolling = 0; gadgetOrientation[0] = GADGET_HORIZONTAL; gadgetOrientation[1] = GADGET_HORIZONTAL; @@ -202,6 +203,34 @@ int FltkViewport::handle (int event) /** \bug Undraw focus box. */ return 1; + case ::fltk::PUSH: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 1; + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + /* pass event so that middle click can open link in new window */ + FltkWidgetView::handle (event); + return 1; + } + break; + + case ::fltk::DRAG: + if (::fltk::event_button() == ::fltk::MiddleButton) { + if (dragScrolling) { + scroll(dragX - ::fltk::event_x(), dragY - ::fltk::event_y()); + dragX = ::fltk::event_x(); + dragY = ::fltk::event_y(); + return 1; + } + } + break; + + case ::fltk::RELEASE: + if (::fltk::event_button() == ::fltk::MiddleButton) { + dragScrolling = 0; + } + break; + case ::fltk::SHORTCUT: switch (::fltk::event_key()) { case PageUpKey: @@ -236,12 +265,9 @@ int FltkViewport::handle (int event) scrollTo (canvasWidth, canvasHeight); /* gets adjusted in scroll() */ return 1; } + } - return FltkWidgetView::handle (event); - - default: - return FltkWidgetView::handle (event); - } + return FltkWidgetView::handle (event); } // ---------------------------------------------------------------------- diff --git a/dw/fltkviewport.hh b/dw/fltkviewport.hh --- a/dw/fltkviewport.hh +++ b/dw/fltkviewport.hh @@ -21,6 +21,7 @@ private: int scrollX, scrollY; int scrollDX, scrollDY; + int dragScrolling, dragX, dragY; ::fltk::Scrollbar *vscrollbar, *hscrollbar;

Oct. 20, 2007