[haiku-appserver] Re: update code.

Hey Adi,

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

Yeah, the clipping region of a View seems to be enforced now. So far so 
good. But some problems remain. I think what I wrote earlier about the 
app_server not drawing with the ViewColor() prior to Draw() being 
called is not correct. The problem must have another cause. But get 
your well deserved sleep first! :-) app_server works already much 
better.

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

Best regards,
-Stephan

Other related posts: