[haiku-appserver] Re: update code.
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 31 Mar 2005 01:46:59 +0300
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:
>>//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:
