×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Odd performance problem

    We have a rather large application -- 110 screens at last count.

    For several parts of this application the performance of the screens (response to touch events mainly) is quite good when the parts (consisting of 10 or so screens) are run stand-alone on a test driver.

    But when integrated into the whole application response to individual touch events becomes sluggish -- like 1/3 of a second. Multiple button presses "stack up" and dribble out over several seconds, while drag events appear to be emitted at a much lower rate, such that much of the drag operation (and what little sensitivity/accuracy there was to begin with) is lost.

    Note that this problem occurs even when only a few screens have been "visited" (and hence created) since application startup, so it's not like storage has been "clogged" by 100 screens. And the code involved isn't doing a whole lot of processing for each touch -- no file or resource file I/O (except maybe what the UI parts are accessing, but I didn't think that happens once the screen has been initially drawn), only creating a few string objects & updating labels, etc.

    Has anyone got any ideas what could be causing this? Does anyone have any ideas on how to debug it? (It is, of course, difficult to tell much about the situation on the emulator.)

  2. #2
    Super Contributor
    Join Date
    Oct 2009
    Posts
    4,326

    Re: Odd performance problem

    http://en.wikipedia.org/wiki/Profili...programming%29
    Note, profiling on desktop is easier in case problem is reproducible there.

  3. #3
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    I'm well aware of profiling. Is there a way to do it in a Symbian environment? (Even if only on the emulator?)

  4. #4
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    Well, tried compiling for gprof profiling with

    QMAKE_CXXFLAGS += -pg
    QMAKE_LFLAGS += -pg

    But got "unrecognized option 'pg'" when I did the build (GCCE).
    [I guess since I was compiling for the emulator that would have been the winscw compiler, not GCCE.]

    Does anyone have any other ideas?

    (I can tell from CPU utilization on the emulator that the problem isn't a constantly-running background task. Rather it's kind of like something has insinuated itself into the event processing path or some such, or maybe a hidden screen is redrawing itself on every visible draw operation.)
    Last edited by danhicksbyron; 2010-04-08 at 06:12.

  5. #5
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    OK, here's something else odd: Just for kicks I provided a NULL parent when constructing one of the problem pages. With that change the performance problem disappears. (Of course, several other problems replace it, but that's to be expected.)

    How could the parent of a screen affect the performance of that screen???

  6. #6
    Super Contributor
    Join Date
    Oct 2009
    Posts
    4,326

    Re: Odd performance problem

    Quote Originally Posted by danhicksbyron View Post
    OK, here's something else odd: Just for kicks I provided a NULL parent when constructing one of the problem pages. With that change the performance problem disappears. (Of course, several other problems replace it, but that's to be expected.)

    How could the parent of a screen affect the performance of that screen???
    Could you explain what do you mean by screen as Qt use different meaning for this term:
    http://doc.trolltech.com/4.6/qdeskto...t.html#details

  7. #7
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    I was intentionally being a little vague, to not imply more than the facts merit. The gory details:

    We have an N97 device screen in landscape with a 140 pixel button area on the right hand edge. The main window widget with those buttons is displayed in full screen (640x360) mode. Then stacked on top of that are 500-pixel wide widgets, oriented to the left edge of the screen, each one a separate logical screen. At the time we have this problem things are stacked maybe 7 screens/widgets deep. The owning widget is 2-3 positions down in the stack.

    I don't see anything particularly odd with the parent -- no oddball event handling, etc, by the parent.

  8. #8
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    I put an event filter on the parent widget and found that it's getting MousePress/MouseRelease/Paint for every mouse click on the visible widget. And presumably it's then propagating those to its other children.

    I thought these events were only supposed to be sent to visible widgets.

    (Is there a comprehensive description somewhere of how events are propagated?)
    Last edited by danhicksbyron; 2010-04-09 at 18:34.

  9. #9
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    However, tracing the version of the application that performs well I see much the same behavior. I'm puzzled, to say the least.

  10. #10
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    I figured out why the mouse events were getting propagated down -- some of the logic was resetting the event "accept" flag. But paint events are still propagating to every page, apparently from the bottom up.

  11. #11
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    setAttribute(Qt::WA_OpaquePaintEvent) seemed to improve performance somewhat, but not to the level of the other example.

  12. #12
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Odd performance problem

    Well, with a judicious sprinkling of WA_OpaquePaintEvent and WA_NoSystemBackground attributes I'm able to achieve 80-90% of the performance of the (unmodified) code running on the test bed.

    Not a clue as to why the difference, other than the system must be (rather stupidly) repainting screens under other opaque screens (in spite of the claims in the documentation that it's smart enough to avoid this), and the additional 2-3 screens in the "real" case is enough to tip the balance.

Similar Threads

  1. Performance problem on Symbian
    By Ikipou in forum Symbian Tools & SDKs
    Replies: 0
    Last Post: 2010-02-02, 20:02
  2. Emulator problem of Symbian S60 5th on vista
    By kason2 in forum Symbian Tools & SDKs
    Replies: 4
    Last Post: 2010-01-31, 15:40
  3. Odd "needs to boot" problem 3rd
    By big_pig in forum Symbian
    Replies: 0
    Last Post: 2007-02-15, 15:36
  4. Theme Studio - Performance problem
    By edudesouza in forum Mobile Java Tools & SDKs
    Replies: 0
    Last Post: 2004-11-16, 16:09
  5. 7210 Silent Problem
    By MarkMckim in forum Mobile Java General
    Replies: 1
    Last Post: 2003-03-18, 12:36

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×