[interfacekit] Re: Clipping - what to do, what to do?


Hi!

Pahtz wrote:
It's really simple for rectangular areas, but how else would you handle arbitrary shapes? With rectangular areas and transparency? 
Treat everthing as a rectangular area. What is a rounded window corner? It's a 
square corner with
a alpha-transparent paint to soften the corner.
It's then up to the window compositing algorithm to lay the windows on top of 
each other so the
stuff under the corner shows through.
He heee... if it is that simple as you say, how do you update the "transparent" part of the window below first one. To actually redraw that part, _that_part_ needs to be part of the window/view requesting the update.
It _can_ be done, I know, I have an idea how... but I have to study further(I am talking here about doing it using transparency[255] - currently it can be done using regions). If you know something about transparency, please contact me in private.
For R1, app_server is not supposed to support transparency, that's why you don't see any code for such a thing. For R2: freeform windows, transparency and double buffering are A MUST.

Then comes the hack, which is for the app_server to pass mouse clicks on fully 
transparent areas
on to a lower window. One pixel check per click is low overhead. [but what 
about MOUSE_MOVED?]
Why would you want that?
If its alpha value is not 255 it means it is still visible and it should receive clicks.

I had done some experimental code 3 years ago for a general virtual frame 
buffer after I had
ported Microwindows (never released). I was going to give it to Darkwyrm but he 
seemed to be
methodical about designing first then implementing, so I didn't want to blinker 
his exploration of
the solution space.
Nice demos. Haven't studied them in detail but I definely think I will look into your sources.

A plausible algorithm for window composition with alpha-blended windows is thus presented.
Hmm... I'll definely look into. :-)

AFTERTHOUGHTS

You don't want to call the client to draw inside your compositing algorithm 
because the client
could lock up the whole loop. But, you need the client data to correctly 
compose alpha-blended
areas. So instead, you should buffer each Window's contents in an offscreen 
bitmap. The advantage
is you can move windows, put windows infront/behind/off-screen, reveal, etc. 
all without sending
expose/invalidate/redraw events to the client - and composition can be done 
with hardware
acceleration. This can be seen in DirectFB.
This is already in plan for R2. Double_Buffering is the key word. :-)

Another note, you need BEGIN_UPDATE and END_UPDATE appserver messages for 
BView::Draw() if you
want to be able to use buffered windows (different from buffering the screen). 
Because without
END_UPDATE the appserver won't know when to blit the invalidated window region.
I know! Was going to do that soon, because the update mechanism is next on my list - so little time, so many things to do! :-(
This weekend I am going to finish with window resizing and tab coloring - all windows have a yellow tab now :-) hi hi hi... which window has the focus? this one. no. :-| that one! no?! I WANT a focus window!!! :-((( :-D

In the BeOS API you're not suppose to call BView::Draw() yourself, but call 
Invalidate() instead.
Furthermore, you shouldn't call drawing instructions outside Draw() as Pulse 
might do. Doing
either breaks (simple) offscreen buffering, i.e., the updates won't been seen.
Yes, you are right. But that does not mean that the drawing should not visible. It's just that double buffering won't be used.


Bye,
Adi



---------------------------------------------------------------
Lucram pentru tine. Analizam. Cautam zilnic.
Alegem ceea ce te intereseaza. Te anuntam.
http://www.REDUCERI.ro/


Other related posts: