[vbox-dev] Chromium WindowDestroy

[Leonid]

Chris Smowton <cs448 at ...> writes:
> > IDs sharing/quessing is really another issue. Some of those are not that 
easy
> > to separate, for example texture ids...it's valid to use *any* id which
> > application chooses, it might be a value returned by glGenTextures but not
> > necessary. So 1 client could really enumerate whole textures namespace if it
> > wants to.
> >    
> Right, but that namespace is private per context, isn't it? If so, it's 
> enough that I can't bind the other guy's context to stop me from abusing 
> his textures.
Guess it requires some carefull checks, there're other things which might be 
shared. For example it's possible to share display lists between contexts 
atleast on win hosts, not sure if it works only for the same process or not.

> > Anyway there're plans to have separate host thread for every client opengl
> > thread, main reason though is to have a dedicated host opengl context per 
guest
> > context. At the same time it'd solve some of the IDs sharing issues.
> >    
> Sounds like that would throw out a lot of Chromium, since half its 
> design was about minimising the state transition when multiplexing 
> renderers -- but then, I'd guess most graphics drivers would respond to 
> a MakeCurrent in similar fashion?
Aye, although we'd still need statetracking for the snapshots support.

> 
> Aside from all that, I've another bug for you: guests sometimes issue a 
> WindowResize with zero width or height; the render SPU's GLX backend 
> translates that unthinkingly into an XResizeWindow, which kills the 
> server with an X error in that case. My solution was to unmap such 
> zero-area windows, setting a flag in their WindowInfo to note that 
> they're not really invisible, but hidden because their size is 
> unreasonable. Then I map them when a more sensible size is specified.
Sounds good, thanks for pointing this.