[haiku-appserver] speed test

Hi guys,

        While playing with the server I decided to make some tests to see why 
the slowliness when moving/resizing one window above other.
        Here are my results:
[These are the 3 main functions that do all the magic inside move/resize]

Moving a window above RootLayer's("white") space:
==============
RebuildRegions
        95-100 ~ 97
Copy window into main mem and copy again to new location:
        3850-3900 ~ 3875
Redraw "white" area which has become visible
        69-1367 ~ 300
Total:
        4272 usecs


Moving a window above other window.
==============
RebuildRegions
        102-111 ~ 106
Copy window into main mem and copy again to new location:
        3971 - 4159 ~ 4065
Redraw "white" area which has become visible
        19978 - 21343 ~ 20660
Total:
        24831 usecs

Resizing a window above another window
==============
RebuildRegions
        126 -138 ~ 132
Copy already visible region(s) into main mem and then copy again to new 
location(s):
        3549 - 4017 ~ 3783
Redraw "white" area which has become visible
        44141 - 44908 ~ 44524
Total:
        48439 usecs


Resizing a window over "white"/RootLayer's space:
===============
RebuildRegions
        113 - 119 ~ 116
Copy already visible region(s) into main mem and then copy again to new 
location(s):
        3587 - 3905 ~ 3746
Redraw "white" area which has become visible
        27419 - 28103 ~ 27761
Total:
        31623 usecs

------------

        Yes... we really have to improve drawing and copyRegions. :-) Region 
rebuilding appears to be quite fast. :-D
        [Note that in none of these cases the client window draws nothing.]

        Now, the reasons for these results (the ones that I can think of):
  * we're using a very slow drawing mechanism - ViewDriver
  * copyRegions could be done better - use the accelerant or use a 
screen-size preallocated area as intermediate buffer (currently malloc 
is called for every rect in every region)
  * decorator needs to be completely redrawn on window resize (maybe, 
just maybe, we can avoid that).

        Now, I know it's not the time for performance talks. I just wanted you 
to present my findings so that we know which parts to be careful about.


Regards,
Adi.

Other related posts: