[haiku-appserver] Re: user needs to know about the clipping region?

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 25 Nov 2005 09:40:40 +0200

Axel Dörfler wrote:

Adi Oanca <adioanca@xxxxxxxxx> wrote:
It's true, we would loose some 2D capabilities like rectangle fill,
But that would only be true if the window buffer wouldn't be in the RAM of the graphics card, right?
(I'm not talking about our current driver interface but about the capabilities of the graphics cards, btw)
Right, but I haven't said or thought of all. :-)
Drawing will be made in a surface in main memory which will be fetched by the graphics hardware in video memory. That surface will be exactly the area that needs to be updated. Why that? Because writing in graphics RAM point by point is more expensive than drawing in main mem and then tell the engine to use AGP 8x or PCI-e to fetch that surface. (This is especially true with antialiased text and gradients but also for a AA primitives)

I'm actually not sure if that assumption is true - it depends on how you draw, and that can be optimized for this case. Video memory should be mapped in "write-combined" mode which makes sure that the writes leave the cache as 32 byte bursts.

It's not an assumption. Telling the graphics card to take a piece of data from main memory is faster (uses AGP) than writing 32 bytes times and times over.


Furthermore, writing the data twice keeps the bus busy twice as long - it might be slower after all.

I'm not sure about that. I'm no specialist in HW, but AFAIK writing in main mem is times faster than writing directly in the graphics card fame buffer(memory).
So, if you write in main mem and then tell the graphics engine/card to take that surface, it will use the AGP bus and have that piece of data in its memory very fast. The other way around is not valuable - writing the surface from the main mem in graphics card is as slow as you would draw each pixel there; AFAIK it uses the PCI bus with FastWrites(if available).


As you see, ATM I have said nothing about HW acc and I guess you realized 2D rectangle fill is totally out. Scrolling is still possible, so is blitting. That may change in future as I think every drawing instruction can be translated into vertices and drawn by the 3D engine, with gradient even! And AA! Even fonts can be accelerated if they are cached in video ram.

For the forseeable future, we cannot rely on 3D graphics, anyway - as we're not Apple or Microsoft, we have to live mostly in the 2D world for some time to come.

I agree. But we can think of that and, still, make it work without 3D HW. When that comes, we already have in place what's needed.


Rudolf's efforts are an exception to this rule, of course, but he probably doesn't want to spend that much time writing 3D drivers for all the hardware we should support :)

Not all HW would support 3D so we must have a backup solution. As I said, we now think at 2D HW, and emulate the 3D for later 3D-capable drivers.


This is what I have thought of. It's an idea to start from. If you agree with the concept I could start writing a paper which we could discuss and improve.

I think we could start having a look at how Mac OS X and Windows do it, and if that's applicable to us, too (or how we can adapt/improve their solution).

Yeap, yesterday I started looking documentation for OSX.


bye, Adi.

Other related posts: