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. Furthermore, writing the data twice keeps the bus busy twice as long - it might be slower after all. > 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. 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 :) > 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). Bye, Axel.