[haiku-appserver] Re: user needs to know about the clipping region?
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 24 Nov 2005 16:00:06 +0200
Hi,
Ingo Weinhold wrote:
May I ask, why you asked the question in the first place?
Short answer: Because I want to remove it. :-) In R2 that is. :-)
Really now, why should the user know about it when there is a clear path to
follow when you want to draw? Also, if you call ClippingRegion() it's very
possible that at the next moment the visible region be different, and in the end
the clipping region you got from the server would serve you nothing.
Those are the reasons why I think this method should not be given into user's
hands. Beside that I have a stronger reason: double buffered windows.
I haven't discussed this with anyone, and I'm struggling to write a mail about
this and other stuff to Stephan, but I just don't find the time. :-(
You guys, don't know yet, but Stephan and I have been talking a lot about
clipping regions and we reached the conclusion that every window(thread) should
take care about the visible regions of its children/Layers.
The problem with double buffering is that we would have "2 clipping regions"
for a Layer/BView. One would be the one visible in the window and the second
would be the one visible on screen - a window may be partially hidden. Which one
should we provide? I say none.
Also, having double buffered windows would spare us converting _any_ drawing
instruction coordinates and the local visible region into screen coords.
It's true, we would loose some 2D capabilities like rectangle fill, but once we
make use of 3D HW and OpenGL, we can have them back. SSE/MMX could help us in
the mean time.
While the removal for ClippingRegion(), IMO, should be done in R2, having
double buffered windows (or at least a prototype) ca be done for R1. And, IMO,
this won't take long at all. We already see Rudolf being able to provide us some
3D capabilities, maybe we can use OpenGL to do that, but ATM I plan to have the
concept working.
bye,
Adi.
Other related posts:
