<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Software-only basic compositing"
href="https://bugs.webkit.org/show_bug.cgi?id=147258#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Software-only basic compositing"
href="https://bugs.webkit.org/show_bug.cgi?id=147258">bug 147258</a>
from <span class="vcard"><a class="email" href="mailto:emanuele.aina@collabora.com" title="Emanuele Aina <emanuele.aina@collabora.com>"> <span class="fn">Emanuele Aina</span></a>
</span></b>
<pre><span class="quote">> Plz blame my laziness. I fixed build of threaded compositor.</span >
Ah ah, no worries, I just picked an unfortunate timing. :)
<span class="quote">> Anyway, It looks like I couldn't understand your use cases properly. Why not using GL accelerated compositing in RPi2? AFAIK, it has enough hardware power.</span >
The current (closed) GL stack has been deemed not reliable enough for WebKit. It works well enough for the limited usage seen in Kodi/XBMC, but WebKit may stress it too much and it has been decided that we will need to get away without GL until the new open stack based on Mesa will be viable.
<span class="quote">> If you want to use threaded-compositor with TextureMapperImageBuffer,
> You don't have to do lots of things.
> just do not use ensureGLContext and glContext()->swapBuffers();
> and make a GraphicsContext from ThreadedCompositor:m_nativeSurfaceHandle and</span >
pass it to TextureMapperImageBuffer implementation.
Indeed that was enough to get the threaded-compositor to work without GL when not actually compositing layers, now I've got position:fixed elements on their own layers (but with a lot of flickering probably due to overdraw) and will look at <video> elements once I have a clear understanding of what causes the flickering.
Thanks!</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>