[haiku-appserver] Re: update code.

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 30 Mar 2005 23:35:59 +0200 CEST

Hi,

> > the views now actually draw themselves, so the situation has much 
> > improved in that regard.
> 
>       They did? How?
>       Tonight I just tested with your 'Window' application and the BView 
> inside the window did not draw correctly.

For me they do, but I have not checked in the changes you told me to 
do. Like ignore all DrawData->clipreg. :-)

> > What I don't understand is this:
> >>    ConstainClippingRegion() should function like BView's version, 
> > > with 
> >>a 
> >>minor difference - passing an empty region should be handled 
> > > exactly 
> >>like when passing NULL.
> > Or do you mean this:
> 
>       This. +
> 
> > 
> > // ConstrainClippingRegion
> > void DisplayDriverPainter::ConstrainClippingRegion(BRegion *region)
> > {
> >     if (region && Lock()) {
> >                     if (!region->Frame().IsValid()) {
> >                             BRegion all;
> >                             RenderingBuffer* buffer = BackBuffer();
> >                             all.Include(BRect(0, 0, buffer->Width() - 1, 
> > buffer
> > ->
> > Height() - 1));
> >                             fPainter->ConstrainClipping(all);
> >                     } else {
> >                             fPainter->ConstrainClipping(*region);
> >                     }
> >             Unlock();
> >     }
>       else if (!region)
>       {
>               BRegion all;
>               RenderingBuffer* buffer = BackBuffer();
>               all.Include(BRect(0, 0, buffer->Width() - 1,
>                       buffer->Height() - 1));
>               fPainter->ConstrainClipping(all);

>               // same as the region is invalid.

No it's not invalid, it's empty. Doesn't make sense of course to issue 
a graphics command then, but I will try this version you posted. Though 
I'm pretty sure it won't fix anything, because it is less restrictive.

> > The first version is more restrictive, so that's what I have tried, 
> > but 
> > it doesn't work well. The clipping in the WindowBorder seems to 
> > work, 
> > but the clipping in the views is like non-existent.
> 
>       What about the 2nd version?

Have not tried yet.

> > Ok, now I understand it better. But I think if it is indeed used 
> > like 
> > that, it should not be part of the DisplayDriver API. For the 
> > simple 
> > reason that such a function should only be part of the API if the 
> > regions are guarenteed not to overlap. ie, they are all transfered 
> > with 
> > the same offset (no point list, just a single BPoint offset). 
> > Because 
> > if this requirement is not met, it means that views need to be 
> > invalidated, and that is not the job of the DisplayDriver to do.
> 
>       :-) Have a look at this:
> http://www.freelists.org/archives/haiku-appserver/01-2005/msg00019.html
> 
Misunderstanding. By "overlapping", I mean that the regions in the list 
are to be moved by different offsets, as opposed to them all being 
moved by the same offset. Please try to understand what that would 
mean. It means you cannot do an in-place copy. (Unless there are more 
requirements on the regions passed to the function.)

What Rudolf was telling you is that you don't need to concern yourself 
with the source and destination rectangle overlapping. That's something 
completely different and it means that in-place copying is still 
possible.

Best regards,
-Stephan



Other related posts: