[haiku-commits] Re: haiku: hrev49843 - src/servers/app/drawing src/servers/app headers/private/interface
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 16 Nov 2015 10:40:46 -0600
On 11/16/2015 04:30, Axel Dörfler wrote:
If each window would have its own bitmap to draw in (ie. actual
compositing), the problem would be solved the only way I can see it
being solved for real.
I faintly remember looncraz working on something like that :-)
The exact point of the stall was something I could never find with
certainty, but it seemed to be on the Desktop all window lock - the only
way to get rid of it was to limit how many threads were trying to gain
the write lock. How many were trying to draw was a non-issue (since my
current version still has every app on the system redraw freely, the
only changea being that the Desktop write lock is no longer acquire as
much and the update frequency is greatly reduced).
It was possible for me to hit push a couple hundred set_ui_color()
commands (which initiated a redraw in every window at once) and the
system would effectively hard freeze. BUT, if you waited long enough,
the stall would eventually go away.
The easiest solution, conceptually, is just to not share locks (having
gone through this, I now understand a really annoying freeze I was
getting with my compositing branch.. I will need to revisit this now
;-)). Of course, as I suggested, using a MultiLocker for each
ServerWindow is the "proper" solution, but it isn't the easiest to
implement. It would require quite a bit of reworking (and a lot of
headaches along the way).
Julian's idea of decoupling off-screen from on-screen windows should
work for his uses, but it doesn't really address the underlying
problem. Drawing does, indeed, happen in parallel, but there are many
cases where the write lock is needed when there is no reason to stop
drawing.
The other option, aside from compositing, is to create a specialized
drawing lock to go with the all window lock. Desktop would then get
bool LockForDrawing() and void UnlockFromDrawing() which would gain read
locks on a MultiLocker and anytime you actually need to prevent drawing
you'd gain the write lock. Right now, drawing stalls (for tiny amounts
of time) across the system all the time frequently when it does not need
to do so, just because Desktop needs to service the window list.
--The loon
Other related posts: