> Hi, > > [ back from vacantion! :-(((( ] Me, too. > ATM our app_server links against libbe.so. What if we include the > rendering code inside this library and use it on server side, as > well as > on client side. This was something which I thought of quite some time ago, if you remember me mentioning a BBitmapUtils class. The concept was to take our DisplayDriver class and build something in userland on top of it which emulates the BView API. > Also, there another 2 big advantages that will be useful in the > near > future. 1) it prepares the ground for double buffering (with > little > hacking we could have this for R1 too :-D ), and 2) we can make > use of > hardware acceleration when available. > Think like this(in near future): there are multiple pipelines in > 3D > hardware for years now; there are this amazing features called > pixel > shaders, all which can help drawing operations perform faster and > a few at > a time. Object Drawer1 should always be used(and reserved to) by > RootLayer > class while the remaining pipelines would be used on client-side > by other > Drawers to draw into bitmaps(which are in videoMem). If we run out > of > pipelines, other Drawers would be instantiated, but this time the > CPU+mainMem would do all the work. Bitmaps are not kept in video memory, so HW acceleration is not possible at this point. IIRC one of the things that Longhorn does is keep bitmaps in the video card's texture memory to do all the nifty tricks that it does. You all probably are aware of my desire to go OpenGL for R2, but what I really want is to leverage the video hardware in general more. Using pixel shaders and other stuff supported by 3D cards is definitely what I wanna see -- just not for R1. The BBitmapUtils class won't technically be R1 -- more like something which is released immediately afterward. If someone would like to play around with something like this before R1's release, we could release it as a separate package and I could host the downloads and such if someone would want me to. --DW