#16356: [app_server] rework updating sessions
--------------------------------+--------------------------
Reporter: stippi | Owner: stippi
Type: task | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: Servers/app_server | Version: R1/beta2
Keywords: | Blocked By:
Blocking: | Platform: All
--------------------------------+--------------------------
If someone manages to get gprof/bprof working properly on R5 (for use in
the test environment), that would be great. Don't forget to tell me how...
:-)
I did manage to get some useful info from ezprof, but I fixed all issues
to the point that the info retrieved from ezprof is now pretty much
inconclusive.
I have thought very much about the performance issues, and have come to
the conclusion, that the problem could very well be in the way "update
sessions" work. Currently, the app_server maintains repainting on the
*window* level of things. There are two update sessions (per window): a
current and a pending update session. The client window paints views in
the current update session which touch the dirty region. The problem here
is, that the mechanism is probably too "coarse": The update session cannot
grow after the window has been informed that repainting needs to be done.
So additional dirty regions are placed in the next (pending) update
session. When the window finally gets to repainting a particular view
after having painted a few views, large portions of it might already be
dirty in the next update session. So it has to be painted again. If the
update sessions worked on the *view* level, instead of the window level
(as seems to be the case in R5, since there is one update message per
view), the dirty region (for each view) might grow for a much longer time
on the server side (while the client window is busy painting other views),
and the window might have to paint the view only once.
I have yet to think of a way, how the update stuff can be moved to the
view level, without wasting too much resources for all those regions. But
I think this is definitely one very important reason for the current
"slowness" of the app_server. The drawing speed itself is likely not the
problem for the majority of the views you see during typical use.
--
Ticket URL: <https://dev.haiku-os.org/ticket/16356>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
