<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 17, 2014 at 11:11 AM, Sam Spilsbury <span dir="ltr"><<a href="mailto:smspillaz@gmail.com" target="_blank">smspillaz@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On Thu, Nov 13, 2014 at 3:28 AM, Kristian Lyngstøl<br>
<<a href="mailto:kristian@bohemians.org">kristian@bohemians.org</a>> wrote:<br>
> So to sum up: Equal stability, fewer features, but actively maintained.<br>
><br>
> In the end I told the user in question that 0.9.12.0 is the latest stable version, but 0.8.9 has more features and is as stable.<br>
<br>
</span>I'm aware of a fork called Fusilli[2] that is a continuation of 0.8<br>
with some redundant features removed.<br></blockquote><div><br></div><div>I'm aware of Fusili. The author contacted me earlier.  One of the major changes is that he removed all config plugins and implemented it directly in core instead. If this sounds familiar, it's because that's what Beryl did too originally.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Otherwise, if I were to give an objective assessment of 0.9, I'd say<br>
that with the right skill set moving the older plugins over to using<br>
modern OpenGL is not particularly hard. Probably one of the hardest<br>
was the blur plugin and that only took me a day or two[3]. The three<br>
biggest changes to rendering were<br>
 1. The move to triangle-based meshes as opposed to relying on quads.<br>
 2. The move from assembly fragment programs to GLSL.<br></blockquote><div> </div><div>What does this actually offer the user, though? I understand what it does for platforms that only has one or the other set of functions of course, but does it actually make a difference for regular old computers where things have just always worked?  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 3. The move to using SwapBuffers (with GLX_EXT_buffer_age) as opposed<br>
to CopySubBuffer. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">1 & 2 are API-incompatible changes. 3 is a change that silently<br>
exposes bugs in existing plugins, usually relating to a failure to<br>
indicate update regions on the screen.<br></blockquote><div><br></div><div>There's a lot of wtf in old plugins, and core for that matter...</div><div><br></div><div>As for 3, that makes a lot of general sense. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In terms of Wayland, I'd honestly recommend look into using something<br>
like libweston and putting a "compiz plugins" compatibility layer on<br>
top of it. That all depends on what compiz plugins actually rely on<br>
from core, but for about 90% of them, not much. Having a GLES<br>
compatible codebase also helps there too, if that's a road one feels<br>
like going down.<br></blockquote><div><br></div><div>I don't think moving compiz over to wayland is worth it, to be blunt. The code base (whatever version) is not a shining example of quality. I'd much rather see the things we miss in the world of Wayland be implemented properly than try to make Compiz move over.</div><div><br></div><div>- Kristian</div></div></div></div>