- Dillo-dev - lists.mailman3.com

Redraw storms

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 03:12:46PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > > > Johannes wrote: > > > > > Yes, I can reproduce it with the tabs example from the fltk2 > > > > tarball (after adding an w->clear_double_buffer() to see the > > > > redraws). > > > > It seems to be related to the MenuTabPager that is used by default. > > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > > > And I like the new look :-) > > > > > > If I hold down ^N until it fills up completely with shrunken tabs, > > > fltk segfaults. > > > > > > > Here it busy loops :-( > > I begin to wonder how long it'll be before we end up on fltk 1.3. Looking at TabGroup.cxx it has a hard limit of 128 tabs :-( For the release, we could simply limit the number of tabs too. There is also a disturbing static array static int p[128]; that makes me wonder if we will run into trouble with multiple TabGroup widgets (one per window) but I might be wrong. Cheers, Johannes

Sept. 23, 2008

Redraw storms

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > > Johannes wrote: > > > Yes, I can reproduce it with the tabs example from the fltk2 > > > tarball (after adding an w->clear_double_buffer() to see the > > > redraws). > > > It seems to be related to the MenuTabPager that is used by default. > > > Switching to ShrinkTabPager solves the problem for me (see patch). > > > And I like the new look :-) > > > > If I hold down ^N until it fills up completely with shrunken tabs, > > fltk segfaults. > > > > Here it busy loops :-( I begin to wonder how long it'll be before we end up on fltk 1.3.

Sept. 23, 2008

Redraw storms

by Johannes.Hofmann＠gmx.de

On Tue, Sep 23, 2008 at 02:51:42PM +0000, corvid wrote: > Johannes wrote: > > On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > > > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > > > opening a new tab every movement of the mouse triggers a redraw. It > > > > doesn't seem to depend on the number of tabs. Usually it will go away > > > > eventually (just after a tab is closed). I upgraded to the latest > > > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > > > this? > > > > > > I saw something similar while developing it. When opening more > > > tabs than the horizontal space, a menu appears to the right. > > > It seldom happened that activating the menu started a "redraw > > > storm" (full CPU usage on mouse MOVE event). > > > > > > I "disappeared" somehow until now... > > > > > > Most probably this is a bug in FLTK2, but it would be good to > > > track it down. Discovering a way to reproduce it reliably would > > > be a big step forward. > > > > Yes, I can reproduce it with the tabs example from the fltk2 > > tarball (after adding an w->clear_double_buffer() to see the > > redraws). > > It seems to be related to the MenuTabPager that is used by default. > > Switching to ShrinkTabPager solves the problem for me (see patch). > > And I like the new look :-) > > If I hold down ^N until it fills up completely with shrunken tabs, > fltk segfaults. > Here it busy loops :-(

Sept. 23, 2008

Redraw storms

by corvid＠lavabit.com

Johannes wrote: > On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > > opening a new tab every movement of the mouse triggers a redraw. It > > > doesn't seem to depend on the number of tabs. Usually it will go away > > > eventually (just after a tab is closed). I upgraded to the latest > > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > > this? > > > > I saw something similar while developing it. When opening more > > tabs than the horizontal space, a menu appears to the right. > > It seldom happened that activating the menu started a "redraw > > storm" (full CPU usage on mouse MOVE event). > > > > I "disappeared" somehow until now... > > > > Most probably this is a bug in FLTK2, but it would be good to > > track it down. Discovering a way to reproduce it reliably would > > be a big step forward. > > Yes, I can reproduce it with the tabs example from the fltk2 > tarball (after adding an w->clear_double_buffer() to see the > redraws). > It seems to be related to the MenuTabPager that is used by default. > Switching to ShrinkTabPager solves the problem for me (see patch). > And I like the new look :-) If I hold down ^N until it fills up completely with shrunken tabs, fltk segfaults.

Sept. 23, 2008

release packaging

by Christian.Kellermann＠nefkom.net

* Jeremy Henty <onepoint(a)starurchin.org> [080923 15:57]: > On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > > The dw package is an awkward case. I think we should bite the bullet > and either move it inside dillo2 or make it an independent package > that the user installs and have dillo2 find and use the installed dw > (and lose the dw-testbed symbolic link). > Sorry for this interruption but what is the reason dw exists? I never understood that. Thanks for your time, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Sept. 23, 2008

Redraw storms

by Johannes.Hofmann＠gmx.de

On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 22, 2008 at 10:51:57AM +0100, Jeremy Henty wrote: > > > > Since dillo got tabs I'm seeing "redraw storms": sometimes after > > opening a new tab every movement of the mouse triggers a redraw. It > > doesn't seem to depend on the number of tabs. Usually it will go away > > eventually (just after a tab is closed). I upgraded to the latest > > FLTK2 snapshot but it has made no difference. Is anyone else seeing > > this? > > I saw something similar while developing it. When opening more > tabs than the horizontal space, a menu appears to the right. > It seldom happened that activating the menu started a "redraw > storm" (full CPU usage on mouse MOVE event). > > I "disappeared" somehow until now... > > Most probably this is a bug in FLTK2, but it would be good to > track it down. Discovering a way to reproduce it reliably would > be a big step forward. Yes, I can reproduce it with the tabs example from the fltk2 tarball (after adding an w->clear_double_buffer() to see the redraws). It seems to be related to the MenuTabPager that is used by default. Switching to ShrinkTabPager solves the problem for me (see patch). And I like the new look :-) Cheers, Johannes

Sept. 23, 2008

release packaging

by onepoint＠starurchin.org

On Tue, Sep 23, 2008 at 07:52:07AM +0200, Andreas Kemnade wrote: > Currently you need to download three tarballs to compile dillo > (fltk,dw,dillo). I doubt that any linux distribution has fltk2 > packages at the moment. (and also not openembedded) What's the plan > about that? FLTK2's API is still not frozen, and its ABI does change quite often so we will have to supply the tarball ourselves. It would be simplest just to keep a copy of the right FLTK2 snapshot on the dillo site under a link saying "use *this* version". The problem is not that distros won't supply packages, the problem is that they *will* and it might be the wrong version. (Expect "I upgraded FLTK2 and Dillo crashed" reports!) The dw package is an awkward case. I think we should bite the bullet and either move it inside dillo2 or make it an independent package that the user installs and have dillo2 find and use the installed dw (and lose the dw-testbed symbolic link). Thoughts? Regards, Jeremy Henty

Sept. 23, 2008

release packaging

by bf2006a＠yahoo.com

--- On Tue, 9/23/08, Andreas Kemnade <akemnade(a)tzi.de> wrote: > Currently you need to download three tarballs to compile > dillo (fltk,dw,dillo). > I doubt that any linux distribution has fltk2 packages at > the moment. > (and also not openembedded) > What's the plan about that? Make one big tarball of > everything > (with some selected fltk snapshot) or do you expect the > distributions > to include a fltk2 package as soon as they see dillo-fltk? fltk2 has been in both FreeBSD Ports: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/fltk2/ (but unfortunately you won't be able to view that with dillo2: "HTTP warning: Content-Type 'text/html' doesn't match the real data." -- fixes?) and NetBSD pkgsrc: http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/fltk2/README.html for some time. I don't see it in Debian's package system or Gentoo portage at the moment, although I'm sure that they, and the other large packaging systems, would add it if asked. I'd prefer to see a separate, smaller tarball containing just dw2 and dillo2, unless fltk2 begins changing more rapidly than the other components, and repeatedly breaks builds or causes the browser to malfunction, in which case it would make sense to bundle a fltk2 snapshot that is known to work with dillo. Regards, b.

Sept. 23, 2008

Redraw storms: the trigger

by onepoint＠starurchin.org

I think the redraw storms start whenever the main window is resized horizontally and there are too many tabs to fit in the horizontal space (so that the tab menu button has appeared). Vertical resizes do not cause the problem. It is also safe to resize horizontally or vertically before the tab menu button appears. Once the storm has started it stops whenever the tab menu button disappears, whether this is due to closing some tabs or widening the window. The storm starts again whenever the tab menu button reappears, whether or not there has been any more resizing. Do other people see this? Jeremy Henty

Sept. 23, 2008

Redraw storms

by onepoint＠starurchin.org

On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote: > I saw something similar while developing it. When opening more tabs > than the horizontal space, a menu appears to the right. It seldom > happened that activating the menu started a "redraw storm" (full CPU > usage on mouse MOVE event). Yes, this is exactly what I'm seeing. Once the redraw storm starts you can stop it by closing tabs or widening the window until all the tabs fit into the horizontal space. But there's got to be more to it than that because the menu usually works OK. Also, sometimes the contents of the tabs stop resizing with the main window once redraw storm starts. Not always, though. Regards, Jeremy Henty

Sept. 23, 2008