[haiku-appserver] Re: primitive drawing, bitmap issue
- From: "Adi Oanca" <adioanca@xxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 28 Jul 2004 19:02:51 +0300
Hello,
>> Hi,
>>
>> [ back from vacantion! :-(((( ]
>Me, too.
Don't you have until the scholl starts?
>> 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.
Yes, I know it was your idea to draw bitmaps on client side.
BBitmapUtils, DisplayDriver, Drawer, they all are the same thing.
>> 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.
I know, that's why I said "near future". ;-)
> 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.
He he, you know I want that too. Unfortunately we won't be able to take
advantages of 3D hardware until
we have support from the drivers - and read here: made by NVidia & ATi.
Rudolf may be able to provide us with *some* 3D futures,
but they will be few. Until we don't have support from at least one of the
2 manufaturers for advanced features we have
to cope with what we have. So, what do we have? We have 2D acceleration
(blitting), acess to video memory and the ability to use it, and AGP
FastWrites support. If you ask me, that is enough for double buffering.
Later, when new 3D functions are implemented in drivers we can start to
use OpenGL, AND, this would be easy because we *already* would have
experience and a great deal of written code.
Let me say where I see this going:
I see a drawing/composition engine (ala Quatz) with 4 (ATM) interfaces:
1) DirectInterface - pretty much what we have now, only better
2) 2DInterface - uses 2D capabilities(blit only) BUT adds double buffering
support by placing bitmaps in videoMem, ready for blitting.
3) 3DInterface - uses 3D capabilities(blit, scalling, rotations, 3D
transformations(surfaces)). Of course, double buffering is there!
4) ShaderInterface - uses the newest 3D capabilities (pixel shaders - for
drawing instructions) (vertex shaders - for transformations)
Uuuu, I'm so excited about this... :-)
> Using pixel shaders and other stuff supported by 3D
>cards is definitely what I wanna see -- just not for R1.
We really can't do that too soon. :-((
>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.
:-) This was exactly what I was thinking. It's easier to just provide a
surface to ServerWindow. R1 will be just like R5. Not that I like that in
this area... :-)).
Adi.
---------------------------------------------------------------
Credite pentru Dacia Logan - Bloombiz.ro
http://www.bloombiz.ro/articol_46916.html
Other related posts:
