On 9/9/2011 10:30 AM, Bas Schouten wrote:
> HI, I'll try and answer some questions here according to my personal ideas as best I can.
> ----- Original Message -----
>> From: "Benoit Jacob" <jacob.b...@gmail.com
>> To: "Bas Schouten" <bsch...@mozilla.com
>> Cc: dev-pl...@lists.mozilla.org
>> Sent: Friday, September 9, 2011 12:27:02 PM
>> Subject: Re: Mobile Gfx Performance
>> Can't we have it both ways? First do the skia backend, which as you
>> said could be done quickly and gives immediate benefits; then start
>> working on option 2 (Emerald) or 3.
> Yes, this was in no way meant as an 'exclusive or' list.
To me, #2 is most appealing, then #3, then #1, because that's the order
from biggest win to smallest. And that is also the order from longest
time-to-completion to shortest. So I could imagine us just trying #2,
then if that doesn't work, #3, then if that doesn't work, #1. But if we
just did the dumb thing of carrying each one all the way through, that's
up to 20 months all told, which seems too long.
- Can we 'fail fast' on either #2 or #3? Say, for Emerald, how long
would it take to prove/disprove whether it can beat Skia or D2D?
- Can we do experiments that might take a week or a few weeks to get
more information about which is most likely to turn out best?
>> A couple of questions about Skia:
>> - can it target D3D? D3D10? or only GL. (And then D3D via ANGLE).
> I believe the latter, but I might be wrong. A lthough I wouldn't be surprised if for performance reasons that would change. At some point they'll likely want to be competitive with Direct2D on windows.
>> - would it be a reasonable "option 1.5" to contribute directly to
>> Skia, in the same way as we've been doing for Cairo?
> Of course this is an options, and I do believe we should, even in the case of also pursuing options 2/3, contribute to Skia where we can. So essentially this 'is' option 1. There's a number of reasons why I wouldn't want to invest like we would in Emerald this way:
> - Skia is controlled by Google. We do not have control over its priorities, API, etc. One reason for the Azure project is to gain this control.
> - I don't think Skia is the 'optimal' API for a hardware accelerated 2D renderer. For Azure we had an opportunity to start from scratch, we took a close look at different APIs like Direct2D, Skia and Cairo and made choices for Azure making it (what we believe to be) the optimalAPI for the future.
> - It doesn't give us an ability to innovate and do something 'better' than the competition. Essentially all the advantages and disadvantages listed in Option 1 still apply.
> Similarly of course, for JS we could use V8, and instead of gecko use Webkit. But in the end that's not what's going to bring innovation and competition to the browser market. I think healthy competition in this field will in the end make all browsers better! Just like IE9 has pushed us and other vendors to ramp up on graphics performance through Direct2D. Obviously this is just my personal opinion.
All good points. We have a little experience with this last year in JS.
- We borrowed the assembler from Nitro (JSC (WebKit)) to use in JM.
We're very happy with that decision--it totally did the job and saved us
a lot of work. We're currently planning to use it in IM, although we
will probably change it more this time.
- To get more regex compilation, instead of building our own, we took
the Yarr regex engine from JSC. I think that was also the right thing to
do, but it hasn't brought about the same level of happiness as the
assembler. The good: Personally, I've not yet been convinced that
compiling JS regexes is all that important in the real world, so I'm not
excited about having someone go off and spend the time to build a whole
regex compiler and advance the state of the art there. Also, we get to
share the work of finding and fixing crashes and security bugs with
Apple, which is nice. The less good: it's a pretty big, complicated code
base, and no one here is terribly interested in living inside Yarr and
becoming a big-time contributor. So, we're kind of dependent on Apple there.
Mapping this back to your points:
- We didn't care to innovate in assemblers (because there's not much to
do) or regex compilers (because we don't see great value to the web), so
we didn't need or want to build our own. Mobile graphics seems very
different: an area ripe for innovation.
- We did need to change the assembler APIs somewhat for JM. We didn't
try to upstream those changes because they were fairly small and we
didn't expect Apple to be interested. We will probably want to change
them more for IM. We might want to upstream those, but if Apple doesn't
want them, we're OK with that. It seems like you have a similar
situation with Skia, where your desire to change the APIs is probably
stronger than your desire to upstream everything.
- With Yarr, having a code base largely controlled by Apple and without
much involvement from our engineers is definitely limiting, but livable,
because awesome regex technology isn't a priority for us. With the
assembler, not so much, just because assemblers are such a simple,
>> - is there a significant overhead in mapping the Azure API onto Skia?
> Significant is hard to define here, personally I'm convinced you could devise a benchmark that shows the mapping overhead just by pushing on the painful points of the mapping. I think and hope the overhead will not be large for 'general' rendering. But it is hard to be sure as long as it isn't fully implemented yet.