[haiku-appserver] Re: drawing thread
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 22 Oct 2004 11:32:51 +0300
Axel Dörfler wrote:
> Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
>
>>>Locking, semaphores. Only one thread draws in the graphicsRAM at a
>>>time.
>>
>> OK. Perfect! That would be Poller Thread if DW agrees.
>
>
> Not really, there can still be any number of threads - they just have
> to be serialized when accessing the same buffer.
Again...
1) double buffering enabled:
Why "many threads"? Don't you agree we should use only one thread for
drawing onscreen?
2) double buffering disabled:
Locking is done by every thread by using DD:AcquireBuffer(*buffer)
_because_ we only have one surface to draw into - the frame buffer.
Better would be to also use a higher priority thread(Poller) for
drawing on screen, but that would involve too much messaging.
> Anyway, you could also use double buffering by only having one copy of
> the whole screen around in main memory
Yes, just like in games. But then, bye bye with window transparency,
shading, etc. effects...
> - I don't know if it makes more
> sense to have different bitmaps for every layer, because that would
> make transparent stuff a lot harder to do.
Au contraire, it would make things much more easy for the composition
engine - just stack layers one above other. Another good thing may be we
able to avoid some clipping calculations.
However, as I already answered DW, this would consume much more system
resources. And for what?, layers inside a window are drawn from back to
front so they appear in the correct order.
What makes sense is to do double buffering at window level. And you
have all my emails of this subject as a prove for that statement.
> When you have a setup like this, all threads could even simultaneously
> access the main memory, since they will all only access their clipping
> region (with potential speed restrictions as well, just like video
> memory, but less drastic). Only if there are more than one thread
> accessing the same region (which can only happen because of
> transparency), they would have to be serialized.
> Of course, having more than one thread drawing off-screen would be
> great for systems with more than one CPU.
I agree, it's a good solution for tearing, but are you prepared to give
up to all that nice effects.
By having this setup, when you move of resize a window you lose
informations(pixels) that this window comes above of. The most drastic
situation is when you move a window because you need to redraw
everything that becomes visible as you move it. Bad!
Regards,
Adi.
Other related posts:
