On Sat, 7 Dec 2002, Brian S. Julin wrote: > > On Sat, 7 Dec 2002, Filip Spacek wrote: > > The greatest issue seems to me how much libgalloc exposes to the exterior. > > Suppose you want to use overlays. You'd use libovl to do that. Now libovl > > will go and negotiate that with libgalloc. This means that libgalloc needs > > to understand overlays as well as libovl. So libgalloc become very > > complicated since it needs to understand everything about the graphics > > card. This is simply unnecessary, i.e. libovl should be the only one that > > understands overlays, it should be libovl that does the resource checking. > > What if you have more than one interface for using overlays? Well, they > > can both be capable of checking the overlay resource, as wasteful as it > > may seem, I seriously doubt we'll ever have two different interfaces for > > accessing overlays (this is just a practical note). > > It's actually quite funny that you chose this as your example. I was > talking to neiljp of fresco and he may have a proposal for just that > instance exactly -- an extension for GGI targets that are window system > based to allow access to things like setting the title bar, resizing, > and... pointers. If we did this we would have both LibOvl and this other > extension potentially contending for any available overlays.
Exactly such an extension does exist: libwmh. libwmh provides features for windowed only targets such as resizing, minimizing, window moving, etc. Those features have nothing to do with overlay resources. libwmh tells the window manager what to do with the GGI window. libovl handles overlay resources _within_ the GGI window. That's the difference. > > So what is so commonly used for us to need some central resource manager? > > Video RAM. In my opinion, libgalloc should only manage video RAM along > > with transfering between video RAM and system RAM (i.e. virtualize > > framebuffer). I one point I had hopes of virtualizing this directly in > > kgi, but there are too many obstacles to overcome and the benefits are not > > that obvious. Right now, libgalloc seems like the best place for this. > > LibGAlloc doesn't just allocate VRAM or other forms of RAM, it > formalizes the capabilities that that RAM has. For example, say you had > an application that wanted to use an ALPHA pixel channel which was > capable of doing "top/bottom" style blending, but your graphics card > only supports "over/under" style blending. LibGAlloc would be able to > tell you this was the case. libgalloc knows _everything_ about the capabilities of its targets from its targets. The user can request resources and features of the resources of libgalloc. The user then knows _how_ to access the resource, but _where_ the resource is actually stored is left to libgalloc's resource management. libgalloc's users are NOT the GGI application writers. libgalloc's direct users are ggi extensions such as libovl, libbuf, libblt... CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
