How to bring up a window really quickly?

[Carsten Haitzler (The Rasterman)]

On Wed, 29 Mar 2006 16:29:05 -0700 "Tamas Kerecsen" <kerecsen at gmail.com>
babbled:

> 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.

unforutnately the kernel likely may swap out X or this process that brings up the window - and thus for x to even RUN the kernel has to swap the relevant pages back in (or re-read them from disk). you can lock things into memory if you run as root and use mlock() (and mlock in all of the code pages as well as heap and stack) to avoid this - i would do this with your client process to start with. as for the xserver - you may need to hack it to do the same. if your process CREATES a window - make it override-redirect (so the wm is never involved in opening it), and open fonts (and actually render the contents of the window once to a temporary pixmap somewhere to ensure all the font data has been loaded in at least once)... then you can do it. but hacking x is pretty invasive. your problem is simply disk io and there not being enough of it to handle the task at hand. you can increase the priority of x and this special client as processes and hope for the best... but thats no guarantee either.

> 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.

see above - you can create without mapping. but again - if x has been swapped out - you are in danger.

>  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)

again - a vt switch is co-operative. x has to be involved in it and cleanly "shut down" the gfx accel for a vt switch. if x is swapped out... back to square 1

>  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.

again - see above. :)

>  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.

yes - as above... could be bad.

>  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.

again - same thing. you need to obtain the lock... if x has 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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)