From: Denis Oliver Kropp <dok@fischlustig.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Jun 1999 14:47:20 +0200

Sucking the marrow out of hardware (Re: libGGI on matroxfb with Mystique)

Marcus Sundberg´s crap from Mit, 16 Jun 1999:
> Denis Oliver Kropp wrote:
> > 
> > Wow,
> > 
> > I started writing a benchmark program for ClanLib.
> > The first test is filled rectangles:
> > within 5 seconds 800x600x16
> > X       326
> > Xlib    75
> > fbdev   23576       <------------
> > 
> > What is this? Is it hardware accelerated?
> 
> Yes, as of LibGGI 2.0beta2.1 matroxfb is hardware accelerated.
> 
> But the results are strange - unless you use very small boxes
> Xlib should be _much_ faster than X on a Matrox card.

Oops, I saw that I use ggiDrawBox only on DirectBuffer targets.
The problem is, that ClanLib has its software rendering, this rendering
is done on a backbuffer, this backbuffer is in system memory (using final
ggiPutBox) if there is no DirectBuffer support. So a call to ggiDrawBox
with Xlib would draw the box in video mem and the final ggiPutBox of
ClanLib´s backbuffer would overwrite it.

A solution would be to implement ALL rendering using ggi calls,
but problems are alpharects, transblits, blits with alpha channel, ...

-----

Which targets don´t support blitting from offscreen space?
Are they emulated then? (sysmem or vidmem, does not matter)

This means: Can I do the following steps with every target?
1. Create a visual with virtual height greater than visible height.
2. ggiPutBox into the resulting "dead" area.
3. ggiCopyBox from them.

-- 
Denis Oliver Kropp (dok)
+ Fischlustig +

ClanBomber, the kick ass game that uses kick ass Clanlib.
www.fischlustig.de/clanbomber	www.clanlib.org

Justice, n.:        A decision in your favor.