[Scummvm-devel] Overlay handling (Was: Virtual keyboard code from GSoC 2008)

[Johannes Schickel]

Max Horn schrieb:
> There are two major problems with this.
>
> 1) The whole vkeybd code runs in its own event loop. If we wanted to  
> show the vkeybd while the game runs, we'd have to redesign this. Like,  
> by setting aside a portion of the screen for the vkeybd, and whenever  
> a click occurs in there, we intercept it.
>   

I guess this one could be handled fairly easily within 
DefaultEventManager. For example it could throw mouse click events first 
at an input to VirtualKeyboard and checking if the vkbd has any means of 
handling that specific event.

> 2) The current overlay code is built around the assumption that the  
> underlying game graphics are frozen. This is yet another thing (of  
> countless others) that would be nice to improve. Some random thoughts  
> on this:
>   

Well actually I'm wondering why we draw it at all on the overlay. We 
could just let backends doing the drawing itself on the real video 
surface or on another overlay which will be merged into the video 
surface last.

Looking at the VirtualKeyboardGUI::redraw method it seems the keyboard 
code assumes all overlay action is frozen meanwhile, at least it only 
fills "_overlayBackup" on startup (and now on screen change events ;-). 
This means if we would allow other code to change the overlay meanwhile 
it would result in graphic glitches when moving the keyboard around. 
This seems wrong to me, actually I don't think our overlay is designed 
to be used by two different clients at all (another reason for me why 
drawing on the overlay is currently a bad idea).

The downside of letting the backend doing all the drawing is of course 
that we can't easily enable the vkbd code on every backend. Also it 
might ugly to have the event code in DefaultEventManager and all the 
drawing must be done by the backend (it gives questions like "how does 
the backend know the position changed?" etc.).

I'm currently unsure on how we should really proceed, but IMHO the 
current overlay sharing approach is definitely not the best way to go :-/.

// Johannes