[haiku-appserver] Re: update code.

Morning Stephan,

Stephan Assmus wrote:
>>      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.
> 
> 
> Ok, you're absolutely right about that. But notice how you cannot tell 
> the Accelerant about any clipping region? That's because the app_server 
> has made sure that the rects to be moved actually make sense. In other 
> words it's the rects that remain *after* clipping has already been 
> applied.

        Aha, now I get what you mean.

> Now, there is no problem to apply the clipping inside the 
> DisplayDriver implementation. BUT app_server needs to make sure that 
> the view  requesting the CopyBits() gets invalidated whereever there
> were no contents on screen before the blit.

        I'm not sure I catch this one.

> That is something the 
> DisplayDriver cannot do for app_server.
> Same goes for the other function with blitting all those regions. If it 
> can be assumed by the DisplayDriver, that the regions are preprocessed, 
> so that they a) don't overlap (so that the same area doesn't get moved 
> twice or more), and b) that the destination rects don't overlap for the 
> different offsets that they may have, this function could be 
> accelerated 3 times. If those requirements cannot be guaranteed, then 
> indeed, your implementation is the fail save one. However, it would 
> draw areas on screen, which would have to be redrawn by the views 
> anyhow. Maybe I find some time to illustrate the problem. I understand 
> perfectly well what you guys had in mind when designing this function, 
> however, I'm saying it is not going to visually work without some 
> additional precautions.

        :-) I did not understood much from the above paragraph, sorry.

        What I did understood is that you complain this method CCR()
should not be inside DD because of clipping operations(?) and there are
performance issues if overlapping occurs.

        I think this function must stay in DD as the HW accelerated subclass
should pass the rectangles found in those regions to the accelerant, by
way of screen_to_screen_blit() hook function. (That HW accelerated subclass
should build a list of blit_params and pass to the accelerant) From this point
it's accelerant's job how to handle things. And he can do _a lot_ better than
what I did in CCR(). He has enough video memory at its disposal so that it can
copy really fast from on-screen to a part of free video memory and then back
again. And if I'm not wrong this is fast enough to be done during a retrace.

        We kinda' need CCR() although it doesn't fully comply with DD
specifications. :-)


bye,
Adi.

Other related posts: