Hi Owen, Could you please move this into bugzilla ?
Thanks, Tomas Owen Taylor wrote: > I was doing some profiling on Mutter in one particular case: alt-Tabbing > with the classic "draw border around window" alt-tab indication. This is > implemented by creating a big window and shaping it to a narrow > rectangle. > > This a pathological way of doing alt-tab indication in the Clutter > universe, but a pretty good test case for the speed of window creation. > > (Running with indirect GL, as normally is done to get the > texture_from_pixmap extension to work via AIGLX.) > > When I looked at the profile, it was very heavily dominated by > glTexImage2D() ... the server was spending > 20% of CPU doing that, and > the client another 11%. (Plus some undetermined amount of kernel time > for wire transport and texture handling.) > > When I investigated *what* glTexImage2D was taking most of the time, it > was a bit funny - the domination was by the calls to glTexImage2D > with a NULL pixels parameter that cogl_texture makes when initializing > a texture. Turns out that Mesa isn't too smart, and even though the > resulting pixmap content is undefined, all the undefined bits get > shipped over the wire and then stored in video memory. > > This is pointless: > > - If we are immediately going to fill the texture with data > - If we were creating the texture to use with texture_from_pixmap > > So, the patch attached makes the initialization with glTexImage2D lazy > so it can either be combined with filling the texture with data or > avoided altogether. > > These changes drop the server time related to glTexImage2D to 7% and the > client time to 6% in a similar test. The result feels much snappier as > well. > > Caveats on the patch: > > - There's a lot of refactoring to consolidate glTexSubImage2D calls > so that it feasible to do the actual change which is pretty trivial. > > - It's not all that well tested - in particular I haven't tested it > in situations where I'm sure texture slicing is happening. It's a > pretty mechanical refactoring of the current code, but there's > obviously potential for introduced error. > > - If someone is calling glTexSubImage2D on the results of > cogl_texture_get_gl_texture() instead of using > cogl_texture_set_region() they'll run into problems, because > the initialization code path will be bypassed. > > - You could obviously make the claim that the proper fix lies in > Mesa ... the glTexImage2D(..., NULL) should just be made fast. > I don't know if that would require GLX wire protocol changes. > > - Owen > > -- To unsubscribe send a mail to [EMAIL PROTECTED]
