Damage as a DIX notion

[Keith Packard]

Eric Anholt <eric at anholt.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160925/cbdaa835/attachment.sig>