FreeLists / haiku-appserver / [haiku-appserver] Re: Transparent bitmap dragging

["Stephan Assmus" <superstippi@xxxxxx>]

Andr=E9 Braga wrote on Thu, 19 May 2005 13:04:05 -0300:

> > 2.) No HW acceleration is available during the dragging, but is
> > unlikely to be needed. (That's unless you implement auto-scrolling 
> > in
> > your applications drop target.)
> 
> I for one happen to rely on this behaviour all the time... =3D3DP
> 
> It was never really fast, though. Maybe the blending could be
> calculated offscreen with SIMD extensions (and plain C++ fallback if
> none are present), and then the resulting bitmap would be blitted to
> the screen; hopefully that's not THAT sluggish (except on my Pentium
> 133).

We don't run out of options so quickly. As was mentioned, we could 
extend the Accelerant interface a little. To me, it looks as if this 
could be done in a totally backwards compatible way. Of course it means 
more work for the driver writers.

To me it looks as if R5 removes the bitmap from screen (restores the 
screen), lets the app draw, then blends the bitmap back onto the 
result. This behaviour is necessary if you don't keep the bitmap and 
rendering buffer separated. In my double buffered approach, this is 
exactly what would happen. The rendering buffer and the bitmap stay 
separated. They are merged in the front buffer, but that is not the 
rendering buffer. So one step is saved, namely the one where you have 
to restore the rendering buffer before the app draws anything. The 
blending is also not done in the frame buffer but during the transfer, 
and should therefor be =5Fa lot=5F faster. (There is the additional step of 
transfering the result though.) If you don't scroll a very large 
portion of the screen, these adventages could mean that the double 
buffered approach is overall faster compared to doing it all in a 
single buffer, even with the advantage of HW accelerated scrolling that 
this has.

Best regards,
-Stephan