QNX RTOS v4 Knowledge Base
QNX RTOS v4 Knowledge Base
| Title |
Photon very slow with many widgets on screen |
| Ref. No. |
QNX.000005754 |
| Category(ies) |
Development |
| Issue |
I have an application that has more than 1000 PtRaw widgets and:
- Photon seems to be too slow if we have such a high number of widgets.
The mouse pointer is unable to move as fast as you move your mouse:
the pointer stops while leaving a PtRaw, stays there for a while, and
suddenly reappear in the correct position where you moved it with your mouse.
- when we try to close our PtWindow the whole Photon shuts down with the
following message: 'Photon terminated (SIGSEGV) at 0005:0000CD97'
My question: how could we solve these problems?
|
| Solution |
The lagging you are noticing is due to the workload that 1000 widgets (all with regions) is imposing on the server. When you take into
consideration that the server must traverse a tree of 1200 nodes to test rectangle intersections, etc on *every* mouse movement within the window, the slowdown doesn't really seem that unreasonable. The crashing on the other hand is bad, and is fixed in Photon 1.14.
There are a number of solutions to the problem (and merely upgrading to 1.14 is probably not the solution of choice since you will still have to contend with the slowness problem):
1. Re-architect the app so that it doesn't require so many raw widgets. Without really knowing the details of your requirements I would have to hazard a guess that you could probably accomplish the same goal using only 1 raw widget without adding too much complexity to your code.
2. Organize the raw widgets into containers of, say, 3 rows of widgets. This means about 10 containers with 120 widgets in each.
Doing this will break photon's internal representation of the regions from 1 tree of 1200 items to 10 trees of 120 items. Since it will only be accessing one tree at a time, doing so will improve your performance about tenfold.
3. Be wary of the types of events you make the widgets sensitive to. Some event types require regions while others don't. If you can restrict your widgets to events that don't require regions, then this should improve performance enormously.
4. You could do the event processing yourself by using a filter callback on the window, using PtContainerHit() and sending the event to the appropriate widget. Still the same amount of work, but it moves the work from the server to the app and will improve the responsiveness of the mouse (the app itself however will be slow and not very responsive)
|
|
