[haiku-appserver] Re: update code.

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 31 Mar 2005 13:14:48 +0200 CEST

Hi,

Stephan wrote:
> is something you cannot do anyways. I'm further saying that the 
> accelerant hook does not do the clipping, but it can however be done 
> in 
> DisplayDriver before passing it on to the accelerant.

The accelerant does not do clipping indeed. You are required to tell it 
what exactly litterally to blit. 

There could be one exception, but you may not rely on that:
(Virtual)screen size clipping. The accelerant in theory could set the 
engine to clip at the borders of a screen (so say 0,0,640,480 or so).

I am not using this. Clipping in my accelerants is disabled: activating 
that means I need more hw registerlevel info. Not always available!

> I hope it is clear now which kind of overlapping I mean. It would be 
> much easier if I draw this out on paper, I guess... :-))

If you would issue blitting commands this way: (in a single cmd to the 
accelerant (one list)
1. blit 0,0,100,100 -> 100,0
2. blit 50,0,150,100 ->400,400 

You have a problem: between 1 and 2 you need to update the rectangle 
50,0,99,100 with content or you will copy partly rubbish during the 
second blit. (I might be a single bit off: it's always hard to envision 
it exactly :)

> I'm pretty sure it does an in-place copy. It just figures out in 
> which 
> direction to read and write the bytes, so that it doesn't read from 
> locations that have already been written to during that operation. 
> Suppose this:

The accelerant does in place copying indeed. Direction is either 
determined by software in the accelerant, or by the HW itself(!)

> And that's correct. Ok, I hope you understand what I mean by in-place 
> copy and what I mean by overlapping. That is the one kind of 
> overlapping. In this case, the destination area overlaps the source 
> area in memory, but that is _no_ problem when you take that into 
> account in your copy algorithm. And I think this is what the graphics 
> engine in the accelerant is doing as well. It does not copy to out of 
> screen regions and then back into visible region at the offset. 
> Unless 
> Rudolf convinces me otherwise... :-)
Nope. I'll most certainly NOT do that! :-)
(stay out of 'my' memory please ;-)


Bye!

Rudolf.


Other related posts: