On Tuesday, December 14, 2010, Benoit Jacob wrote: > Different users have different priorities. For example, Gecko wants > pixel-exact rendering
risking being "pedantic" ... this isn't actually true. it's true most of the time, but some of the time pixel perfect is irrelevant. "*gasp*, what?" case in point: bluring. when a blur is applied, it's not important to ensure "pixel perfection" for what is being blurred. this is one kind of trick that driver writers rely on to optimize such cases, but they can only do so by recognizing the state+shader fingerprint of that, which is typically application specific. as a result of these identifiable fingerprints, they can avoid overhead in some blurs which remove "must be pixel-perfect here" as a requirement. this the kind of thing (to over-generalize/-simplify) they do to make blurred areas in various games and the blur in windows 7 so performant. (i'm told that win7 uses a rather sub-optimal blur algo, actually, but that because it can be "fingerprinted" by the driver, windows drivers are highly optimized for it and so it's very fast in spite of the implementation.) the moral here is that it's probably best to present as uniform an appearance as we can to the drivers (which is a combination of state+shader, not an API) and let the graphics gurus show us what we actually need ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
