Eric Anholt <[email protected]> writes: > In talking with ajax, I came around to "just compute the bounds up > front, always."
That's certainly simpler. It would be useful to go and measure how much of firefox's (and maybe other applications?) rendering is aimed at pixmaps without damage tracking enabled. > All glamor ops will want the damage for scissoring (we're already > setting scissors all the time, so now we just intersect the new incoming > box with the scissor we were going to set). All window ops want the > damage for compositing. Software cursor wants it for screen. Basically > what get from the kinda complicated lazy damage API is avoiding damage > computation for pixmap-only rendering. The question is whether damage-less rendering happens enough to be worth this effort. That includes both pixmap rendering and non-composited desktops. Text is probably the most interesting operation for which server request overhead is significant (the other being dots). > I think the approach outlined here would also work. I'm just not > convinced it's necessary. A data-driven approach would be awesome here. Do we have a reasonable performance metric? I'm no fan of gratuitous complexity, but text performance is pretty important to me. Maybe we can have our cake and eat it too -- is there any reason we couldn't use a more complex mechanism for just a few operations? The only interaction would be in the mi text code where it would have to force the bounds computation before reverting to the spans code. Speaking of text, the current core text interface doesn't work for glamor -- I need the original character data along with the glyph pointers, so glamor currently duplicates the glyph lookup stuff. In addition, that API kinda sucks as it elides missing glyphs without any indication. If we replaced the core text API with one that delivered the chars and glyphs together, we could reduce the number of GC functions and also make computing the bounds not involve doing the glyph lookups twice (once in damage, once in glamor). I know core text shouldn't matter, but there's a bunch of duplicate code here. Another thought -- I wrote wrapper functions for Render drawing which do all of the validation etc. We should do the same for all of the core APIs and then go root out all of the places which call through the gc ops directly. This would be an easy place to stick damage, eliminating a layer in the drawing stack, and also eliminating a few ValidateGC calls. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
