How to bring up a window really quickly?

Tamas Kerecsen kerecsen at gmail.com
Wed Mar 29 15:29:05 PST 2006


Hi everyone,

I need some help with an unusual requirement...

I'm working on a project that runs on an x86 Linux (2.6.9) machine with
several X (6.8.1) applications (some using graphics acceleration/3D
conceivably).
I need the following functionality: When an external event arrives (such as
a critical error) I'd like to be able to quickly display a screen that would
cover any other windows in existence. This should happen in a half a second
or so, even when the PC is heavily loaded.

Unfortunately when some (even low priority) application causes memory
swapping by allocating/freeing a large block, any (even RT priority)
application is blocked from memory allocation until the first allocation is
sorted out. When switching applications, the X server (and probably the X
lib too) tries to do memory allocation, and thus displaying the screen slows
to a crawl.

So the obvious solution (running a full screen X client that displays the
desired screens, putting it in the background; then bringing it on top  when
needed) is not working. Sometimes bringing the window forward and redrawing
it takes several (tens of) seconds.

Here are some of the options I considered. Please comment on which one looks
feasible (or whether there is a simpler way). As you will see, I'm willing
to consider hacking X, or anything else to get what I want :) However, it
would be cool if I could leave the X server alone.

 1. Displaying a transparent window over any window, and drawing to it at
the critical moment -> if X slows down, I have a feeling this drawing will
slow down too, unless I put some hack in X that treats this overlay in a
special way somehow. I'm also not sure if X has facilities for such a
transparent window.

 2. Switching to another VT, then displaying the emergency screen by writing
to the frame buffer -> this re-initalizes the VGA board, leading to the
screen going blank (for quite a long time on some monitors)

 3. Wrestling ownership of the display board from X through DRM -> due to
the extremely sparse documentation, I'm not sure how X (and the video board)
would behave if it was in the middle of something (such as rendering a 3D
scene). Or whether DRM will even allow me to get control when X is busy
using the board.

 4. Doing an "mlockall" on X so it always has readily available memory ->
this may lead to some nasty memory management issues if I allocate a ton of
physical RAM for X (or if I don't pre-allocate enough pages, it can again
get unresponsive). In addition, I'm worried that the interaction between X
and a foreground applications that is busy trashing can slow down X
nonetheless.

 5. Inserting a short-circuit in X that allows a client to immediately draw
the entire screen through DRI (or some similar method) -- I'm not sure how
complex is it to trigger a context switch and let the application draw
through it.

 6. Buying a video board that is able to do hardware overlays or can handle
multiple screen buffers. My emergency app would flip the switch in the video
card to display the appropriate overlay/screen buffer -- are there any such
beasts out there that don't break the bank?

Please comment!

Thanks a lot in advance,
  Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20060329/f23dc4ac/attachment.html>


More information about the xorg mailing list