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? Regards, Jeremy Henty
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. -- Cheers Jorge.-
On Mon, Sep 22, 2008 at 11:24:17AM -0400, Jorge Arellano Cid wrote:
Most probably this is a bug in FLTK2,
That's what I thought so I upgraded FLTK2 to see if that helped. It didn't. :-(
Discovering a way to reproduce it reliably would be a big step forward.
I'll post anything I find. I also noticed that once the redraw storm started it could happen even if the current tab was static but some of the other hidden tabs were still loading. Regards, Jeremy Henty
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
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
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.
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 :-(
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.
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
On Tue, Sep 23, 2008 at 03:12:46PM +0000, corvid wrote:
I begin to wonder how long it'll be before we end up on fltk 1.3.
Me too. It seems to me that FLTK-2 is not stabilising within any reasonable time and the developers are now giving most of their effort to FLTK-1.3. (They're even devoting lots of time to <gasp> the documentation!!!) Does/will FLTK-1.3 have tabs? Regards, Jeremy Henty
On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann 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).
Confirmed.
It seems to be related to the MenuTabPager that is used by default. Switching to ShrinkTabPager solves the problem for me (see patch).
Yes, this also works for the fltk2 tabs example, just add fltk::TabGroup::default_pager (fltk::PAGER_SHRINK); But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as above, select tab4 and narrow the window then the text of "very long tab text" appears at the other side of tab4 and obscures tab3! Time for a visit to the FLTK bug tracker. Regards, Jeremy Henty
Replying to myself:
On Tue, Sep 23, 2008 at 04:03:17PM +0200, Johannes Hofmann wrote:
Switching to ShrinkTabPager solves the problem for me (see patch).
Yes, this also works for the fltk2 tabs example, just add
fltk::TabGroup::default_pager (fltk::PAGER_SHRINK);
But, <sigh>, it's also buggy. If you hack the fltk2 tabs example as above, select tab4 and narrow the window then the text of "very long tab text" appears at the other side of tab4 and obscures tab3!
I'm sorry for being so negative. Thanks, Johannes, for confirming that it's a FLTK bug and finding a workaround. I would prefer the default pager if it worked because it gives a list of all tabs, but at the moment this bug makes the shrink pager far better.
Time for a visit to the FLTK bug tracker.
I've raised reports for the redraw storm and tab text display issues: http://www.fltk.org/str.php?L2047 http://www.fltk.org/str.php?L2048 Regards, Jeremy Henty
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org