Fabio Alemagna <[EMAIL PROTECTED]> wrote: > Not necessarily, it just requires a way to centralize memory allocations.
You are only talking about memory. I have already shown that and how it can be done. How do you handle half-done accelerator commands? I have not yet heard a convincing way to handle them. Just disallow them would of course do. But I suppose that is not an option. > Why would that be complicated? You have one or more surfaces on which you > display things, after VT switching you still have one or more surfaces on > which you display things. And you have an application that is stuck in a piece of code (within the library) like this: accelreg[DATA_REG]=some_setup_stuff; /* VT switch happens here */ accelreg[CMD_REG]=some_command; Now what do we do with that? Map some memory there? This will cause the app to believe it has completed the draw command. => The membuffer is in an inconsistent state. Wait for the accel to be idle? It _is_ idle at that point. we've just set up some parameter before the switch occurred. Tell the app to clean up somehow? Cleaning up might be difficult, as the app would have to locate exactly where the switch happened. And if we have to tell the app, why then don't we just tell the app right from the start and have it clean up _before_ we mess with it. As long as vtswitch can happen in a place like the one above, you _will_ have to alter program flow afterwards to somewhat gracefully deal with the situation. And it is pretty difficult to do that, especially as it depends very closely on where the switch occurred. > > You miss, that in X, you never talk to the graphics HW directly. X will > > send you an event when you iconify, and will nicely gobble up all > > your funny drawing requests if you don't act on it. > Not completely true: if backing store is active the rendering will still > happen on a backbuffer. YES. But not BY THE APPLICATION. The application _always_ talks to the X-server. The X server draws. and it knows about all the iconfication stuff (it is sending out the events itself, so ...) and it can stop using acceled drawing commands in a nice manner, as it controls the _complete_ accelerator and does not need to preempt it. If all graphics stuff happens in a central place and you just talk to it and that central place also _controls_ inconification (aka VT-switching), all is well, as the central place can just change its rendering mapping when it generates the iconify-Message. You can now of course advocate to make KGI that place. Fine with me. But the performance freaks will not be pleased, if they have to cross protection rings just to draw an accelerated box. > > Seems like we are not talking about the same thing. What I advocate is: > > 1. Tell the app, if it looses visibility. > > 2. Let the app decide what to do. > > Doing that behind its back won't work out. > Yes it would. The world is full of examples where it works. Yeah. Under very specific constraints. I can do it easily if I just have framebuffers. I can do it easily, if I route all accel stuff through a central authority and either let it provide fallback rendering (yeah, I can hear the kernel people scream, if we put a complete graphics engine in there) or have the code calling into it check for errors in every instance. I can do it easily on graphics hardware that uses main RAM, can be saved/restored nicely and can be told to just keep blitting to that piece of RAM, even though it is not visible. But I can't do it on typical PC hardware when I want to access the accel stuff with as little overhead as possible. > Even in AROS it works, so I don't see why it shouldn't work in KGI. Show me code, that works in the direct-accel-access scenario I depicted above, that does not need the application to cooperate or using something of outrageous complexity like emulating the graphics hardware with pagefaults (VMWare-Style). Cu, Andy -- = Andreas Beck | Email : <[EMAIL PROTECTED]> =
