[haiku-commits] Re: BRANCH looncraz-github.CAP-volatile - /
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 07 Nov 2012 13:01:57 -0800
On 11/7/2012 09:35, Axel DÃrfler wrote:
I'm breaking the compositing engine down into its basic components.
[...]
2. Decorator drawing into the same, enlarged, bitmap.
a. while maintaining ability to render directly into frame buffer
i. loses alpha effects - preferred OFF when those effects are
disabled
I don't understand the purpose of this change, though.
Care to elaborate?
If the decorator draws directly to the screen it will need to be redraw
on updates, so it must be buffered for compositing. If we create a
separate buffer we waste space. We would also limit effects to just the
window contents. I use one buffer for the decorator, window, and
shadows. The only area where this becomes complex is with the change of
using one decorator to encompass multiple windows with Stack&Tile. I am
still investigating how to handle this.
However, if decorator effects are off, such as shadows, then it might
well be better to have the decorators draw directly to the frame buffer
as they do now. This can save RAM, but is also the fall-back for when
compositing or buffering is disabled. Personally, I am just leaving it
open so we can always fall back to the current state until my code is
stable/accepted.
3. Bitmap cursor and new cursor drawing logic.
What will change there exactly? At least we don't even support a
hardware cursor ATM (that would be a nice addition, too).
The way the current cursor is drawn is problematic with compositing.
The cursor will become a high-priority, last-drawn, element for each
frame. Using a bitmap with a hotspot will allow fancier cursors. A
hardware cursor will be required eventually, but until then the cursor
needs to not cause severe tearing as it does in my test app_server w/
compositing enabled. The prioritization of the hardware cursor will
come about when I can see the behavior of the modified cursor logic (the
old cursor logic well remain as a fall-back).
4. Actual compositing.
a. Clipping changes.
b. Update/Frame rate control.
c. default window drawing to redirect, with opt-outs
d. special allowances for non-interactive overlays
i. text dialogues (think volume level indicators)
ii. special effects - such as screen savers or cute animations
iii. animated mouse cursors
In what will that differ from standard window (besides being not
completely opaque and square, that is)?
Bye,
Axel.
You will get the standard benefits from compositing. Alpha effects,
shaping (using BPicture, maybe?.. maybe even Dano compatible?) ,
flicker-free, scaling, live previews, filtering effects (contrast,
inversion, etc), etc... These will all come about slowly - for now, I'm
just wanting to get the basics up and running and working as it does now
(though some performance will be lost, and some gained, and much more
RAM will be required when activated).
Due to the CPU-bound nature of this work, at least for now, there will
need to be some considerably performance tracking abilities as well, so
windows which are taking longer to update their contents (such as VLC,
or a game) can be intelligently directed directly to the frame-buffer.
For now, I am just working on making ONE window draw into a
WindowBuffer, the decorator draw - with its own DrawingEngine - to the
frame buffer, and have the WindowBuffer contents drawn properly into the
frame buffer. Step one ;-)
-- I will address the code concerns in a follow-up email.
--The loon
Other related posts:
