[haiku-appserver] Re: update code.

Damn, I can't hold myself. :-)))

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

        Aha, please try now, with both ConstrainClippingRegion implementations.


> 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.

        I think the first version would suffice. This one is good for 
testing/seeing "hidden" things (things that shouldn't be there). :-)))
        I prefer the 2nd. :-D

>>>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.

        Hm...

 From Accelerant.h:
typedef struct {
        uint16  src_left;       /* guaranteed constrained to virtual width and 
height */
        uint16  src_top;
        uint16  dest_left;
        uint16  dest_top;
        uint16  width;  /* 0 to N, where zero means one pixel, one means two 
pixels, etc. */
        uint16  height; /* 0 to M, where zero means one line, one means two 
lines, etc. */
}

typedef void (*screen_to_screen_blit)(engine_token *et, blit_params 
*list, uint32 count);


        Seems to me one can move 'n' rectangles to whatever distinct 
destination it wishes.


Bye,
Adi.

Other related posts: