- Dillo-dev - lists.mailman3.com

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

Scrolling patch!

by Johannes.Hofmann＠gmx.de

> Hi there, > > 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! Very nice! This was really missing. Johannes

Oct. 20, 2007

Re: bug: non-ascii characters not displayed correctly in the title bar

by matthias.franz＠ujf-grenoble.fr

On Fri, Oct 19, 2007 at 07:05:07PM -0300, dillo-dev-bounces(a)dillo.org wrote: > Can you display special characters in you terminal prompt? > e.g.: > > server$ ??? yes Dillo1 displays the title bar correctly. I use icewm as window manager. I have compiled fltk2 with --disable-xft. -- Matthias Franz

Oct. 20, 2007

directory listings?

by bogus＠does.not.exist.com

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. -- Cheers Jorge.-

Oct. 20, 2007

Scrolling patch!

by bogus＠does.not.exist.com

Hi there, 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! The dw2 part of the patch is attached to this email, so Sebastian can look at a minor change that looks like a fix for a hidden bug in the code... The patch is complete in CVS. -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by bogus＠does.not.exist.com

On Fri, Oct 19, 2007 at 08:49:48PM +0200, Matthias Franz wrote: > Hi, > > by default, I use Latin1 encoding on my machine, not UTF-8. > Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. > Here is an example: > > <title>dillô</title> > <body> > dillô > </body> > > You don't get "dill?" in the title bar, but "dill??". Strange, it works for me either with "en" or "latin1". I don't use utf-8 with mrxvt. Can you display special characters in you terminal prompt? e.g.: server$ ??? -- Cheers Jorge.-

Oct. 20, 2007

bug: non-ascii characters not displayed correctly in the title bar

by matthias.franz＠ujf-grenoble.fr

Hi, by default, I use Latin1 encoding on my machine, not UTF-8. Dillo2 does not do UTF-8 -> Latin1 conversion for the title bar. Here is an example: <title>dillô</title> <body> dillô </body> You don't get "dill?" in the title bar, but "dill??". Cheers, -- Matthias Franz

Oct. 19, 2007