eSeaMonkey 1.1.4 freezes UI at times - OS2

This is a discussion on eSeaMonkey 1.1.4 freezes UI at times - OS2 ; I see this most often when I need to use PrefBar to toggle the colors prior to loading/reloading a tab referencing a webpage that has a bad color scheme. I am on an older system, an IBM ThinkPad 600E, and ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: eSeaMonkey 1.1.4 freezes UI at times

  1. eSeaMonkey 1.1.4 freezes UI at times

    I see this most often when I need to use PrefBar to toggle the colors
    prior to loading/reloading a tab referencing a webpage that has a bad
    color scheme. I am on an older system, an IBM ThinkPad 600E, and I have
    at times seen my entire UI lockup for 20 minutes when toggling. I wouldn't
    mind if this simply locked up my browser, but locking up the entire UI is
    unacceptable.

    I thought perhaps this was a problem with PrefBar, so I opened a bug
    report with the author. You can see my report here:

    https://www.mozdev.org/bugs/show_bug.cgi?id=17514

    The author's response, however, points to eSeaMonkey for OS/2 as the
    problem:

    >I don't think it's Prefbar freezing the UI.
    >
    >All Prefbar is doing is toggling a configuration variable true/false.
    >You can generate the same effect by going to the URL, about:config and
    >searching for "browser.display.use_document_colors". You can then click
    >it to change it true/false.
    >
    >It might just be the OS/2 implementation of SeaMonkey. Maybe SeaMonkey
    >is taking a long time re-rendering the page without the Document's
    >specified colors. I don't have this problem with my Win2k version of
    >SeaMonkey (v1.1.4).


    If my vague recollections of how OS/2's SIQ works is correct the bug is
    that for some reason eSeaMonkey is using the thread that holds the SIQ to
    apply the update to the configuration variable as opposed to a separate
    thread. These same recollections are that IBM's guideline is that any
    action that requires over 100 msecs of realtime should be performed in a
    separate thread as opposed to the main one.

    I can see from OSRM2 Lite that eSeaMonkey uses multiple threads, six at
    present as I look, so it would appear that some threading is being done
    now. If my analysis is correct all that would be needed to fix my
    situation would be to delegate the update to another thread or use a new
    one.

    Surely I am not the only one seeing this problem. I may be seeing it
    magnified by quite a bit given my older equipment, but certainly it is not
    proper for eSeaMonkey to hog the SIQ and lock other programs out while it
    updates.

    -- Dave
    -----------------------------------------------------------
    dhdurgeeverizonnet
    -----------------------------------------------------------


  2. Re: eSeaMonkey 1.1.4 freezes UI at times

    me@privacy.net wrote:
    > I see this most often when I need to use PrefBar to toggle the colors
    > prior to loading/reloading a tab referencing a webpage that has a bad
    > color scheme. I am on an older system, an IBM ThinkPad 600E, and I have
    > at times seen my entire UI lockup for 20 minutes when toggling. I wouldn't
    > mind if this simply locked up my browser, but locking up the entire UI is
    > unacceptable.
    >
    > I thought perhaps this was a problem with PrefBar, so I opened a bug
    > report with the author. You can see my report here:
    >
    > https://www.mozdev.org/bugs/show_bug.cgi?id=17514
    >
    > The author's response, however, points to eSeaMonkey for OS/2 as the
    > problem:
    >
    >> I don't think it's Prefbar freezing the UI.
    >>
    >> All Prefbar is doing is toggling a configuration variable true/false.
    >> You can generate the same effect by going to the URL, about:config and
    >> searching for "browser.display.use_document_colors". You can then click
    >> it to change it true/false.
    >>
    >> It might just be the OS/2 implementation of SeaMonkey. Maybe SeaMonkey
    >> is taking a long time re-rendering the page without the Document's
    >> specified colors. I don't have this problem with my Win2k version of
    >> SeaMonkey (v1.1.4).

    >
    > If my vague recollections of how OS/2's SIQ works is correct the bug is
    > that for some reason eSeaMonkey is using the thread that holds the SIQ to
    > apply the update to the configuration variable as opposed to a separate
    > thread. These same recollections are that IBM's guideline is that any
    > action that requires over 100 msecs of realtime should be performed in a
    > separate thread as opposed to the main one.
    >
    > I can see from OSRM2 Lite that eSeaMonkey uses multiple threads, six at
    > present as I look, so it would appear that some threading is being done
    > now. If my analysis is correct all that would be needed to fix my
    > situation would be to delegate the update to another thread or use a new
    > one.
    >
    > Surely I am not the only one seeing this problem. I may be seeing it
    > magnified by quite a bit given my older equipment, but certainly it is not
    > proper for eSeaMonkey to hog the SIQ and lock other programs out while it
    > updates.
    >
    > -- Dave
    > -----------------------------------------------------------
    > dhdurgeeverizonnet
    > -----------------------------------------------------------
    >

    Are there transparent pngs involved? The Mozilla apps take a very slow
    route displaying transparent pngs which often block everything until
    drawn. Scrolling etc restarts the whole thing. Don't know the speed of
    your thinkpad but on a Pentium class CPU I could easily see it blocking
    for 20 minutes.
    Perhaps prefbar itself uses transparent pngs? In which case you could
    fix things by changing the transparent pngs to something else (Peter had
    to do this to Firefox a couple of times when the theme started using
    transparent pngs).
    Ok looking at the screenshot of prefbar it does look like it uses
    transparent pngs.
    The bug is fixed on trunk due to using Cairo for rendering now but trunk
    is not very usable right now. Unluckily it also looks like prefbar does
    not work on trunk yet
    Dave
    ps see https://bugzilla.mozilla.org/show_bug.cgi?id=167884

  3. Re: eSeaMonkey 1.1.4 freezes UI at times

    In <7p1Ei.38590$vP5.22214@edtnps90>, on 09/07/2007
    at 01:00 AM, Dave Yeo said:

    ....snipped...

    >Are there transparent pngs involved? The Mozilla apps take a very slow
    >route displaying transparent pngs which often block everything until
    >drawn. Scrolling etc restarts the whole thing. Don't know the speed of
    >your thinkpad but on a Pentium class CPU I could easily see it blocking
    >for 20 minutes.


    Could be, never checked. According to mplayer my CPU is:

    CPU: Intel Celeron A Mendocino/Pentium II Dixon
    (Family: 6, Model: 6, Stepping: 10) [366 MHz]
    CPUflags: MMX: 1 MMX2: 0 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0

    >Perhaps prefbar itself uses transparent pngs? In which case you could
    >fix things by changing the transparent pngs to something else (Peter had
    >to do this to Firefox a couple of times when the theme started using
    >transparent pngs).
    >Ok looking at the screenshot of prefbar it does look like it uses
    >transparent pngs.
    >The bug is fixed on trunk due to using Cairo for rendering now but trunk
    >is not very usable right now. Unluckily it also looks like prefbar does
    >not work on trunk yet


    Perhaps this will address things in the future, but there is still a
    problem at present.

    As noted in the bug report and my prior posts, what I am seeing seems to
    be OS/2 specific. I can live with not being able to interact with
    SeaMonkey while the colors are being updated, but I can't live with being
    unable to interact with anything on my system at all while the update is
    going on! Someone needs to get this update out of the main thread that
    locks the SIQ and onto a secondary thread!

    -- Dave
    -----------------------------------------------------------
    dhdurgeeverizonnet
    -----------------------------------------------------------


  4. Re: eSeaMonkey 1.1.4 freezes UI at times

    me@privacy.net wrote:

    > As noted in the bug report and my prior posts, what I am seeing seems to
    > be OS/2 specific. I can live with not being able to interact with
    > SeaMonkey while the colors are being updated, but I can't live with being
    > unable to interact with anything on my system at all while the update is
    > going on! Someone needs to get this update out of the main thread that
    > locks the SIQ and onto a secondary thread!
    >

    Well I tried prefbar (on firefox instead of seamonkey so I could easily
    remove it) and it seems I was wrong about the transparent pngs (unless
    the page you're toggling has them). With firefox I don't see any UI
    blocking when toggling colour or any thing else I tried. My CPU isn't
    much more then twice as fast as yours so it should show up.
    One other suggestion is to create a new virgin profile and try
    installing prefbar there and see if you get the same results.
    I'll try it on Seamonkey (same version as yours) later when I'm not
    doing anything.
    Dave

  5. Re: eSeaMonkey 1.1.4 freezes UI at times

    In , on 09/07/2007
    at 04:32 AM, Dave Yeo said:

    >me@privacy.net wrote:


    >> As noted in the bug report and my prior posts, what I am seeing seems to
    >> be OS/2 specific. I can live with not being able to interact with
    >> SeaMonkey while the colors are being updated, but I can't live with being
    >> unable to interact with anything on my system at all while the update is
    >> going on! Someone needs to get this update out of the main thread that
    >> locks the SIQ and onto a secondary thread!
    >>

    >Well I tried prefbar (on firefox instead of seamonkey so I could easily
    >remove it) and it seems I was wrong about the transparent pngs (unless
    >the page you're toggling has them). With firefox I don't see any UI
    >blocking when toggling colour or any thing else I tried. My CPU isn't
    >much more then twice as fast as yours so it should show up. One other
    >suggestion is to create a new virgin profile and try installing prefbar
    >there and see if you get the same results. I'll try it on Seamonkey (same
    >version as yours) later when I'm not doing anything.


    Perhaps it has something to do with the fact that I normally browse with
    13 tabs open. I have recently created a new profile, so I doubt that is
    related to the problem. I saw the same problem in the new as the old. If
    you need more details let me know.

    -- Dave
    -----------------------------------------------------------
    dhdurgeeverizonnet
    -----------------------------------------------------------


  6. Re: eSeaMonkey 1.1.4 freezes UI at times

    On Thu, 6 Sep 2007 14:12:13 UTC, me@privacy.net wrote:

    > I thought perhaps this was a problem with PrefBar, so I opened a bug
    > report with the author. You can see my report here:
    >
    > https://www.mozdev.org/bugs/show_bug.cgi?id=17514
    >
    > The author's response, however, points to eSeaMonkey for OS/2 as the
    > problem:
    >
    > >I don't think it's Prefbar freezing the UI.
    > >
    > >All Prefbar is doing is toggling a configuration variable true/false.
    > >You can generate the same effect by going to the URL, about:config and
    > >searching for "browser.display.use_document_colors". You can then click
    > >it to change it true/false.
    > >
    > >It might just be the OS/2 implementation of SeaMonkey. Maybe SeaMonkey
    > >is taking a long time re-rendering the page without the Document's
    > >specified colors. I don't have this problem with my Win2k version of
    > >SeaMonkey (v1.1.4).


    Are you aware that you can get a similar effect (temporarily) with the
    "zap colors" bookmarklet from
    ?

    And what happens if you toggle "browser.display.use_document_colors" by
    hand (using about:config)? And on which URL are you trying this?

    Btw, I am not aware of having released v1.1.4 of eSeaMonkey but it
    shouldn't really matter if you are talking about eSM 1.1.3 or official
    SM 1.1.4. Both work fine here, the color change is instantaneous (done
    by hand Prefbar doesn't want to install).
    --
    Greetings, | My From: address is valid as is the version without "spam"
    Peter. | I try to find real messages among the spam once a week

  7. Re: eSeaMonkey 1.1.4 freezes UI at times

    On Fri, 7 Sep 2007 11:43:39 UTC, me@privacy.net wrote:

    > Perhaps it has something to do with the fact that I normally browse with
    > 13 tabs open.


    Ah, that might make some difference. I just loaded 17 fairly complex or
    long pages in tabs and worked the respective setting from about:config
    in another window. The update then took maybe half a second. I guess
    that on your slow processor it might take a while indeed. Please note
    that while README.txt recommends a 500 MHz processor for acceptable
    performance, I wouldn't really want to use anything below 1 GHz and with
    lots of RAM...

    Btw, before you continue on the SIQ stuff: that really ceased to be a
    problem a long time ago when pressing Ctrl-Esc would take the focus away
    from the current (maybe locked) app. And changing the code to draw on a
    secondary thread will not happen in Mozilla anytime soon, certainly not
    for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    cross-platform changes.
    --
    Greetings, | My From: address is valid as is the version without "spam"
    Peter. | I try to find real messages among the spam once a week

  8. Re: eSeaMonkey 1.1.4 freezes UI at times

    In , on 09/09/2007
    at 12:45 PM, "Peter Weilbacher" said:

    >On Fri, 7 Sep 2007 11:43:39 UTC, me@privacy.net wrote:


    >> Perhaps it has something to do with the fact that I normally browse with
    >> 13 tabs open.


    >Ah, that might make some difference. I just loaded 17 fairly complex or
    >long pages in tabs and worked the respective setting from about:config
    >in another window. The update then took maybe half a second. I guess
    >that on your slow processor it might take a while indeed. Please note
    >that while README.txt recommends a 500 MHz processor for acceptable
    >performance, I wouldn't really want to use anything below 1 GHz and with
    >lots of RAM...


    I run on the hardware I have, not the hardware I would like to have. I
    have maximized the RAM on the system and Theseus shows I am not yet
    hitting memory problems. So my critical resource is the CPU itself.

    >Btw, before you continue on the SIQ stuff: that really ceased to be a
    >problem a long time ago when pressing Ctrl-Esc would take the focus away
    >from the current (maybe locked) app. And changing the code to draw on a
    >secondary thread will not happen in Mozilla anytime soon, certainly not
    >for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    >cross-platform changes.


    Ctl-Esc may take the focus away when I have this problem, but a pop-up
    window offering to close the offending application or cancel is all I get.
    Of course I don't want to close SeaMonkey, I want to be able to change the
    focus to another application.

    You note drawing on a secondary thread will not happen any time soon, can
    what I am asking for be accomplished in some other manner? Could a
    timeout in a loop of some sort be used such that the SIQ is able to deal
    with such things as changing focus to another application? Can
    interaction with the SIQ be placed in a separate thread that will get its
    share of the CPU even when the thread drawing the screen if using all the
    CPU it can get?

    Keep in mind I have only a cursory knowledge of OS/2 programming, so I may
    be making totally off-the-wall suggestions about how to do what seems
    necessary to correct a problem with an otherwise great program. I trust
    that you and other dedicated OS/2 programmers can translate my feeble
    babbling into something that can address the problem faced by those of us
    running on older, but still quite functional, hardware out here.

    -- Dave
    -----------------------------------------------------------
    dhdurgeeverizonnet
    -----------------------------------------------------------


  9. Re: eSeaMonkey 1.1.4 freezes UI at times

    me@privacy.net wrote:
    > In , on 09/09/2007
    > at 12:45 PM, "Peter Weilbacher" said:
    >
    >> On Fri, 7 Sep 2007 11:43:39 UTC, me@privacy.net wrote:

    >
    >>> Perhaps it has something to do with the fact that I normally browse with
    >>> 13 tabs open.

    >
    >> Ah, that might make some difference. I just loaded 17 fairly complex or
    >> long pages in tabs and worked the respective setting from about:config
    >> in another window. The update then took maybe half a second. I guess
    >> that on your slow processor it might take a while indeed. Please note
    >> that while README.txt recommends a 500 MHz processor for acceptable
    >> performance, I wouldn't really want to use anything below 1 GHz and with
    >> lots of RAM...

    >
    > I run on the hardware I have, not the hardware I would like to have. I
    > have maximized the RAM on the system and Theseus shows I am not yet
    > hitting memory problems. So my critical resource is the CPU itself.
    >
    >> Btw, before you continue on the SIQ stuff: that really ceased to be a
    >> problem a long time ago when pressing Ctrl-Esc would take the focus away
    >>from the current (maybe locked) app. And changing the code to draw on a
    >> secondary thread will not happen in Mozilla anytime soon, certainly not
    >> for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    >> cross-platform changes.

    >
    > Ctl-Esc may take the focus away when I have this problem, but a pop-up
    > window offering to close the offending application or cancel is all I get.
    > Of course I don't want to close SeaMonkey, I want to be able to change the
    > focus to another application.
    >

    ....

    I've been playing with prefbar, cpu is 800 Mhz Duron, have about 40 tabs
    open and clicking the colour button does tie Seamonkey up for upwards of
    a minute. I can often bring another app to the foreground and usually
    double clicking the desktop or Seamonkey will bring up the window list.
    Ctrl-Esc sometimes offers to kill Seamonkey and sometimes brings up the
    window list. For it to take upwards of 20 minutes on your system is
    strange as your CPU isn't that slow.
    Dave

  10. Re: eSeaMonkey 1.1.4 freezes UI at times

    In , on 09/09/2007
    at 05:43 PM, Dave Yeo said:

    >me@privacy.net wrote:
    >> In , on 09/09/2007
    >> at 12:45 PM, "Peter Weilbacher" said:
    >>
    >>> On Fri, 7 Sep 2007 11:43:39 UTC, me@privacy.net wrote:

    >>
    >>>> Perhaps it has something to do with the fact that I normally browse with
    >>>> 13 tabs open.

    >>
    >>> Ah, that might make some difference. I just loaded 17 fairly complex or
    >>> long pages in tabs and worked the respective setting from about:config
    >>> in another window. The update then took maybe half a second. I guess
    >>> that on your slow processor it might take a while indeed. Please note
    >>> that while README.txt recommends a 500 MHz processor for acceptable
    >>> performance, I wouldn't really want to use anything below 1 GHz and with
    >>> lots of RAM...

    >>
    >> I run on the hardware I have, not the hardware I would like to have. I
    >> have maximized the RAM on the system and Theseus shows I am not yet
    >> hitting memory problems. So my critical resource is the CPU itself.
    >>
    >>> Btw, before you continue on the SIQ stuff: that really ceased to be a
    >>> problem a long time ago when pressing Ctrl-Esc would take the focus away
    >>>from the current (maybe locked) app. And changing the code to draw on a
    >>> secondary thread will not happen in Mozilla anytime soon, certainly not
    >>> for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    >>> cross-platform changes.

    >>
    >> Ctl-Esc may take the focus away when I have this problem, but a pop-up
    >> window offering to close the offending application or cancel is all I get.
    >> Of course I don't want to close SeaMonkey, I want to be able to change the
    >> focus to another application.
    >>

    >....


    >I've been playing with prefbar, cpu is 800 Mhz Duron, have about 40 tabs
    >open and clicking the colour button does tie Seamonkey up for upwards of
    >a minute. I can often bring another app to the foreground and usually
    >double clicking the desktop or Seamonkey will bring up the window list.
    >Ctrl-Esc sometimes offers to kill Seamonkey and sometimes brings up the
    >window list. For it to take upwards of 20 minutes on your system is
    >strange as your CPU isn't that slow.


    I haven't seen it that bad for a bit, but I still see 30 seconds to a
    minute or two lately. Perhaps swapping my 6GB drive for a newer 40GB one
    has something to do with this. I have also started using the "Clear
    Cache" button on PrefBar before hitting the "Colors" toggle in case that
    might improve things.

    How are you getting another app to the foreground? I usually find
    clicking on another app ineffective if I am having this problem. I
    sometimes get a "clang" of some sort but often it does nothing. Also as
    noted I almost always get the pop-up offering to kill SeaMonkey with
    ctl-esc, which is useless. I would have to guess I manage to get a window
    list 1% of the time with ctl-esc at best.

    I am glad you are at least able to replicate the condition. Now the $24
    question is how can this be addressed in SeaMonkey? I assume it would be
    an OS/2 only fix, although I remember one post on the bug to the effect
    that it was a problem on Linux as well. I assume there to be other cases
    that would cause a similar problem if SeaMonkey became excessively busy
    drawing for another reason that would likewise lock the system up. So I
    don't see this as specific to PrefBar.

    -- Dave
    -----------------------------------------------------------
    dhdurgeeverizonnet
    -----------------------------------------------------------


  11. Re: eSeaMonkey 1.1.4 freezes UI at times

    me@privacy.net wrote:
    > In , on 09/09/2007
    > at 05:43 PM, Dave Yeo said:
    >
    >> me@privacy.net wrote:
    >>> In , on 09/09/2007
    >>> at 12:45 PM, "Peter Weilbacher" said:
    >>>
    >>>> On Fri, 7 Sep 2007 11:43:39 UTC, me@privacy.net wrote:
    >>>>> Perhaps it has something to do with the fact that I normally browse with
    >>>>> 13 tabs open.
    >>>> Ah, that might make some difference. I just loaded 17 fairly complex or
    >>>> long pages in tabs and worked the respective setting from about:config
    >>>> in another window. The update then took maybe half a second. I guess
    >>>> that on your slow processor it might take a while indeed. Please note
    >>>> that while README.txt recommends a 500 MHz processor for acceptable
    >>>> performance, I wouldn't really want to use anything below 1 GHz and with
    >>>> lots of RAM...
    >>> I run on the hardware I have, not the hardware I would like to have. I
    >>> have maximized the RAM on the system and Theseus shows I am not yet
    >>> hitting memory problems. So my critical resource is the CPU itself.
    >>>
    >>>> Btw, before you continue on the SIQ stuff: that really ceased to be a
    >>>> problem a long time ago when pressing Ctrl-Esc would take the focus away
    >>> >from the current (maybe locked) app. And changing the code to draw on a
    >>>> secondary thread will not happen in Mozilla anytime soon, certainly not
    >>>> for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    >>>> cross-platform changes.
    >>> Ctl-Esc may take the focus away when I have this problem, but a pop-up
    >>> window offering to close the offending application or cancel is all I get.
    >>> Of course I don't want to close SeaMonkey, I want to be able to change the
    >>> focus to another application.
    >>>

    >> ....

    >
    >> I've been playing with prefbar, cpu is 800 Mhz Duron, have about 40 tabs
    >> open and clicking the colour button does tie Seamonkey up for upwards of
    >> a minute. I can often bring another app to the foreground and usually
    >> double clicking the desktop or Seamonkey will bring up the window list.
    >> Ctrl-Esc sometimes offers to kill Seamonkey and sometimes brings up the
    >> window list. For it to take upwards of 20 minutes on your system is
    >> strange as your CPU isn't that slow.

    >
    > I haven't seen it that bad for a bit, but I still see 30 seconds to a
    > minute or two lately. Perhaps swapping my 6GB drive for a newer 40GB one
    > has something to do with this. I have also started using the "Clear
    > Cache" button on PrefBar before hitting the "Colors" toggle in case that
    > might improve things.


    Ok thats more in line with what I see. I have a very small cache and use
    a proxy for caching (Oops). Even just now tried nicing Seamonkey down to
    idle+31 and it doesn't make much difference.

    >
    > How are you getting another app to the foreground? I usually find
    > clicking on another app ineffective if I am having this problem. I
    > sometimes get a "clang" of some sort but often it does nothing. Also as
    > noted I almost always get the pop-up offering to kill SeaMonkey with
    > ctl-esc, which is useless. I would have to guess I manage to get a window
    > list 1% of the time with ctl-esc at best.


    I find double clicking the other app works the best. Usually do get an
    error clang, sometimes the app only half draws then hangs until
    Seamonkey finishes but the window list almost always appears and often
    can be used to change focus. Usually Seamonkey still has the dark blue
    title bar like it has focus and fuzzy borders. At this point you really
    don't want to click on Seamonkey as everything will stop for a bit.
    >
    > I am glad you are at least able to replicate the condition. Now the $24
    > question is how can this be addressed in SeaMonkey? I assume it would be
    > an OS/2 only fix, although I remember one post on the bug to the effect
    > that it was a problem on Linux as well. I assume there to be other cases
    > that would cause a similar problem if SeaMonkey became excessively busy
    > drawing for another reason that would likewise lock the system up. So I
    > don't see this as specific to PrefBar.


    Well as Peter stated he does not have the time or interest in fixing it,
    much more important things to fix like getting Seamonkey 2.0 usable. And
    sadly Peter is just about the only coder working on Mozilla.
    I also suspect that it may well be OS/2 that needs fixing as it seems to
    be the PM that is blocking while redrawing. So people like us who are
    using older hardware just have to live with it.
    I do see exactly the same behaviour on some sites that use a lot of
    Javascript to display the page. Look at it as a chance to take a
    bathroom break or get a cup of coffee
    Dave

  12. Re: eSeaMonkey 1.1.4 freezes UI at times

    On Sep 9, 4:13 pm, m...@privacy.net wrote:
    > In , on 09/09/2007
    > at 05:43 PM, Dave Yeo said:
    >
    >
    >
    > >m...@privacy.net wrote:
    > >> In , on 09/09/2007
    > >> at 12:45 PM, "Peter Weilbacher" said:

    >
    > >>> On Fri, 7 Sep 2007 11:43:39 UTC, m...@privacy.net wrote:

    >
    > >>>> Perhaps it has something to do with the fact that I normally browse with
    > >>>> 13 tabs open.

    >
    > >>> Ah, that might make some difference. I just loaded 17 fairly complex or
    > >>> long pages in tabs and worked the respective setting from about:config
    > >>> in another window. The update then took maybe half a second. I guess
    > >>> that on your slow processor it might take a while indeed. Please note
    > >>> that while README.txt recommends a 500 MHz processor for acceptable
    > >>> performance, I wouldn't really want to use anything below 1 GHz and with
    > >>> lots of RAM...

    >
    > >> I run on the hardware I have, not the hardware I would like to have. I
    > >> have maximized the RAM on the system and Theseus shows I am not yet
    > >> hitting memory problems. So my critical resource is the CPU itself.

    >
    > >>> Btw, before you continue on the SIQ stuff: that really ceased to be a
    > >>> problem a long time ago when pressing Ctrl-Esc would take the focus away
    > >>>from the current (maybe locked) app. And changing the code to draw on a
    > >>> secondary thread will not happen in Mozilla anytime soon, certainly not
    > >>> for SeaMonkey 1.1.x or even 2.0.x. That would depend on major
    > >>> cross-platform changes.

    >
    > >> Ctl-Esc may take the focus away when I have this problem, but a pop-up
    > >> window offering to close the offending application or cancel is all I get.
    > >> Of course I don't want to close SeaMonkey, I want to be able to change the
    > >> focus to another application.

    >
    > >....
    > >I've been playing with prefbar, cpu is 800 Mhz Duron, have about 40 tabs
    > >open and clicking the colour button does tie Seamonkey up for upwards of
    > >a minute. I can often bring another app to the foreground and usually
    > >double clicking the desktop or Seamonkey will bring up the window list.
    > >Ctrl-Esc sometimes offers to kill Seamonkey and sometimes brings up the
    > >window list. For it to take upwards of 20 minutes on your system is
    > >strange as your CPU isn't that slow.

    >
    > I haven't seen it that bad for a bit, but I still see 30 seconds to a
    > minute or two lately. Perhaps swapping my 6GB drive for a newer 40GB one
    > has something to do with this. I have also started using the "Clear
    > Cache" button on PrefBar before hitting the "Colors" toggle in case that
    > might improve things.
    >
    > How are you getting another app to the foreground? I usually find
    > clicking on another app ineffective if I am having this problem. I
    > sometimes get a "clang" of some sort but often it does nothing. Also as
    > noted I almost always get the pop-up offering to kill SeaMonkey with
    > ctl-esc, which is useless. I would have to guess I manage to get a window
    > list 1% of the time with ctl-esc at best.
    >
    > I am glad you are at least able to replicate the condition. Now the $24
    > question is how can this be addressed in SeaMonkey? I assume it would be
    > an OS/2 only fix, although I remember one post on the bug to the effect
    > that it was a problem on Linux as well. I assume there to be other cases
    > that would cause a similar problem if SeaMonkey became excessively busy
    > drawing for another reason that would likewise lock the system up. So I
    > don't see this as specific to PrefBar.
    >
    > -- Dave
    > -----------------------------------------------------------
    > dhdurgeeverizonnet
    > -----------------------------------------------------------


    I have a sneaky feeling that if you disable the Innotek Font Engine
    for the browser, your hangs will disappear. Disable with regedit2.

    Jim


+ Reply to Thread