Delay all Screen Updates Until the End - Motif

This is a discussion on Delay all Screen Updates Until the End - Motif ; I have some logic that creates a large number of screens. Each screen causes data to be fetched from the database. As a result, the screens get half-painted as the system load climbs. Is there a way to create the ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Delay all Screen Updates Until the End

  1. Delay all Screen Updates Until the End


    I have some logic that creates a large number of screens. Each screen
    causes data to be fetched from the database. As a result, the screens
    get half-painted as the system load climbs. Is there a way to create
    the screens but prevent anythung from being rendered until all the work
    is completed. Maybe I would put up one screen that saus "We are very
    busy" and all the other screen painting won;t happen until all the setup
    work is completed. I would expect that would reduce the load since the
    server won't need to paint and everything would execute must more
    quickly.

    Am I making any sense?

    Thanks.

    ....Jake

    --
    Jake Colman
    Director of Software Development
    Principia Partners LLC
    101 West Elm Street
    Suite 620
    Conshohocken, PA 19428
    +1 (610) 755-9786
    www.principiapartners.com

    --
    Posted via a free Usenet account from http://www.teranews.com


  2. Re: Delay all Screen Updates Until the End

    On Mar 30, 6:46*pm, Jake Colman wrote:
    > I have some logic that creates a large number of screens. *Each screen
    > causes data to be fetched from the database. As a result, the screens
    > get half-painted as the system load climbs. *Is there a way to create
    > the screens but prevent anythung from being rendered until all the work
    > is completed. *Maybe I would put up one screen that saus "We are very
    > busy" and all the other screen painting won;t happen until all the setup
    > work is completed. *I would expect that would reduce the load since the
    > server won't need to paint and everything would execute must more
    > quickly.
    >
    > Am I making any sense?


    When you say you create "screens", this makes me think you are not
    using Motif, but rather some Microsoft windows app. This newsgroup is
    for discussing Motif applications on Unix/Linux platforms.


    If indeed you are using Motif and you mean you create several dialogs,
    just unmanage the shell widget until you are finished filling it, then
    manage the shell.

    --
    Fred Kleinschmidt

  3. Re: Delay all Screen Updates Until the End

    >>>>> "flk" == fred l kleinschmidt writes:

    flk> On Mar 30, 6:46*pm, Jake Colman wrote:

    >> I have some logic that creates a large number of screens. *Each
    >> screen causes data to be fetched from the database. As a result,
    >> the screens get half-painted as the system load climbs. *Is there
    >> a way to create the screens but prevent anythung from being
    >> rendered until all the work is completed. *Maybe I would put up
    >> one screen that saus "We are very busy" and all the other screen
    >> painting won;t happen until all the setup work is completed. *I
    >> would expect that would reduce the load since the server won't
    >> need to paint and everything would execute must more quickly.
    >>
    >> Am I making any sense?


    flk> When you say you create "screens", this makes me think you are
    flk> not using Motif, but rather some Microsoft windows app. This
    flk> newsgroup is for discussing Motif applications on Unix/Linux
    flk> platforms.

    flk> If indeed you are using Motif and you mean you create several
    flk> dialogs, just unmanage the shell widget until you are finished
    flk> filling it, then manage the shell.

    Hi, Fred. Yes, I am definitely using Motif. We are creating top-level
    shells and fetching the widgets from a UIL file. Within a loop, I am
    creating a shell and feteching data from a database to populate the
    various widgets within a shell. I have a progress dialogue that
    displays progress as we do the work. If I test this logic with an
    increasing number of iterations, everything slows down. In other words,
    opening 20 windows takes more than twice the time as 10 windows.

    What do you suggest for this? Are shells automatically managed when
    created? Or automaically mapped? Would changing this behavior making
    things faster?

    --
    Jake Colman
    Director of Software Development
    Principia Partners LLC
    101 West Elm Street
    Suite 620
    Conshohocken, PA 19428
    +1 (610) 755-9786
    www.principiapartners.com

    --
    Posted via a free Usenet account from http://www.teranews.com


  4. Re: Delay all Screen Updates Until the End

    On Apr 1, 10:23*am, Jake Colman wrote:
    > >>>>> "flk" == fred l kleinschmidt writes:

    >
    > * *flk> On Mar 30, 6:46*pm, Jake Colman wrote:
    >
    > * *>> I have some logic that creates a large number of screens. *Each
    > * *>> screen causes data to be fetched from the database. As a result,
    > * *>> the screens get half-painted as the system load climbs. *Is there
    > * *>> a way to create the screens but prevent anythung from being
    > * *>> rendered until all the work is completed. *Maybe I would put up
    > * *>> one screen that saus "We are very busy" and all the other screen
    > * *>> painting won;t happen until all the setup work is completed. *I
    > * *>> would expect that would reduce the load since the server won't
    > * *>> need to paint and everything would execute must more quickly.
    > * *>>
    > * *>> Am I making any sense?
    >
    > * *flk> When you say you create "screens", this makes me think you are
    > * *flk> not using Motif, but rather some Microsoft windows app. This
    > * *flk> newsgroup is for discussing Motif applications on Unix/Linux
    > * *flk> platforms.
    >
    > * *flk> If indeed you are using Motif and you mean you create several
    > * *flk> dialogs, just unmanage the shell widget until you are finished
    > * *flk> filling it, then manage the shell.
    >
    > Hi, Fred. *Yes, I am definitely using Motif. *We are creating top-level
    > shells and fetching the widgets from a UIL file. *Within a loop, I am
    > creating a shell and feteching data from a database to populate the
    > various widgets within a shell. *I have a progress dialogue that
    > displays progress as we do the work. *If I test this logic with an
    > increasing number of iterations, everything slows down. *In other words,
    > opening 20 windows takes more than twice the time as 10 windows.
    >
    > What do you suggest for this? *Are shells automatically managed when
    > created? *Or automaically mapped? *Would changing this behavior making
    > things faster?


    The top widget in the UIL tree (4th parameter of MrmFetchWidget) is
    initially
    unmanaged. Be sure you are doing things in this order:

    status = MrmFetchWidget( ..., &my_widget, ... );

    /* do other thijngs here to set dynamic contents of widgets in
    * the tree with my_widget at the top
    */

    XtManageChild( my_widget );

    In other words, be sure to manage the widget AFTER you fill in
    the other information.
    --
    Fred Kleinschmidt

  5. Re: Delay all Screen Updates Until the End

    >>>>> "flk" == fred l kleinschmidt writes:

    flk> On Apr 1, 10:23*am, Jake Colman wrote:
    >> >>>>> "flk" == fred l kleinschmidt
    >> >>>>> writes:

    >>
    >> * *flk> On Mar 30, 6:46*pm, Jake Colman wrote:
    >>
    >> * *>> I have some logic that creates a large number of
    >> screens. *Each * *>> screen causes data to be fetched from the
    >> database. As a result, * *>> the screens get half-painted as the
    >> system load climbs. *Is there * *>> a way to create the screens
    >> but prevent anythung from being * *>> rendered until all the work
    >> is completed. *Maybe I would put up * *>> one screen that saus "We
    >> are very busy" and all the other screen * *>> painting won;t
    >> happen until all the setup work is completed. *I * *>> would
    >> expect that would reduce the load since the server won't * *>>
    >> need to paint and everything would execute must more quickly. *
    >> *>> * *>> Am I making any sense?
    >>
    >> * *flk> When you say you create "screens", this makes me think you
    >> are * *flk> not using Motif, but rather some Microsoft windows
    >> app. This * *flk> newsgroup is for discussing Motif applications
    >> on Unix/Linux * *flk> platforms.
    >>
    >> * *flk> If indeed you are using Motif and you mean you create
    >> several * *flk> dialogs, just unmanage the shell widget until you
    >> are finished * *flk> filling it, then manage the shell.
    >>
    >> Hi, Fred. *Yes, I am definitely using Motif. *We are creating
    >> top-level shells and fetching the widgets from a UIL file. *Within
    >> a loop, I am creating a shell and feteching data from a database
    >> to populate the various widgets within a shell. *I have a progress
    >> dialogue that displays progress as we do the work. *If I test this
    >> logic with an increasing number of iterations, everything slows
    >> down. *In other words, opening 20 windows takes more than twice
    >> the time as 10 windows.
    >>
    >> What do you suggest for this? *Are shells automatically managed
    >> when created? *Or automaically mapped? *Would changing this
    >> behavior making things faster?


    flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
    flk> is initially unmanaged. Be sure you are doing things in this
    flk> order:

    flk> status = MrmFetchWidget( ..., &my_widget, ... );

    flk> /* do other thijngs here to set dynamic contents of widgets in
    flk> * the tree with my_widget at the top
    flk> */

    flk> XtManageChild( my_widget );

    flk> In other words, be sure to manage the widget AFTER you fill in
    flk> the other information.
    flk> --
    flk> Fred Kleinschmidt


    So if I have text fields that display values based on the record of data
    being loaded into the window or option lists that get initiaized to a
    specific value based on that record, I call XtManageChild() only after
    all data loading is complete and I have specified the value for each
    widget?


    --
    Jake Colman
    Director of Software Development
    Principia Partners LLC
    101 West Elm Street
    Suite 620
    Conshohocken, PA 19428
    +1 (610) 755-9786
    www.principiapartners.com

    --
    Posted via a free Usenet account from http://www.teranews.com


  6. Re: Delay all Screen Updates Until the End

    >>>>> "Jake" == Jake Colman writes:

    >>>>> "flk" == fred l kleinschmidt writes:

    flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
    flk> is initially unmanaged. Be sure you are doing things in this
    flk> order:

    flk> status = MrmFetchWidget( ..., &my_widget, ... );

    flk> /* do other thijngs here to set dynamic contents of widgets in
    flk> * the tree with my_widget at the top
    flk> */

    flk> XtManageChild( my_widget );

    flk> In other words, be sure to manage the widget AFTER you fill in
    flk> the other information.
    flk> --
    flk> Fred Kleinschmidt

    Jake> So if I have text fields that display values based on the
    Jake> record of data being loaded into the window or option lists
    Jake> that get initiaized to a specific value based on that record, I
    Jake> call XtManageChild() only after all data loading is complete
    Jake> and I have specified the value for each widget?

    I apologize for following up my own post.

    How does XtManageChild() relate to whether the screen is or is not
    displayed, that is, viewable to the user. If the screen is not visible,
    would I still have a performance hit if I have called XtManageChild()
    before I am done initializing all the data in the widgets?

    --
    Jake Colman
    Director of Software Development
    Principia Partners LLC
    101 West Elm Street
    Suite 620
    Conshohocken, PA 19428
    +1 (610) 755-9786
    www.principiapartners.com

    --
    Posted via a free Usenet account from http://www.teranews.com


  7. Re: Delay all Screen Updates Until the End

    On Apr 1, 8:49*pm, Jake Colman wrote:
    > >>>>> "Jake" == Jake Colman writes:
    > >>>>> "flk" == fred l kleinschmidt writes:

    >
    > * *flk> The top widget in the UIL tree (4th parameter of MrmFetchWidget)
    > * *flk> is initially unmanaged. Be sure you are doing things in this
    > * *flk> order:
    >
    > * *flk> status = MrmFetchWidget( ..., &my_widget, ... );
    >
    > * *flk> /* do other thijngs here to set dynamic contents of widgets in
    > * *flk> * the tree with my_widget at the top
    > * *flk> */
    >
    > * *flk> XtManageChild( my_widget );
    >
    > * *flk> In other words, be sure to manage the widget AFTER you fill in
    > * *flk> the other information.
    > * *flk> --
    > * *flk> Fred Kleinschmidt
    >
    > * *Jake> So if I have text fields that display values based on the
    > * *Jake> record of data being loaded into the window or option lists
    > * *Jake> that get initiaized to a specific value based on that record,I
    > * *Jake> call XtManageChild() only after all data loading is complete
    > * *Jake> and I have specified the value for each widget?
    >
    > I apologize for following up my own post.
    >
    > How does XtManageChild() relate to whether the screen is or is not
    > displayed, that is, viewable to the user. *If the screen is not visible,
    > would I still have a performance hit if I have called XtManageChild()
    > before I am done initializing all the data in the widgets?
    >


    When you retrieve the widget tree with MrmFetchWidget, nothing is
    visible until you call XtManageChild on the retrieved top widget.

    You may or may nbot get a performance hit by managing the widget
    before filling in all the data. The main thjing that would cause
    performance hits is if internal sizing depends on the contents of the
    widgets (if text fields are not fixed size, but grow or shrink based
    on the contents), if there are lists (fill all items in the list
    before it
    is managed; otherwise it redraws every time a new item is added), etc.

    --
    Fred Kleinschmdit

+ Reply to Thread