[FusionComm] Truly disappointing

[Alyssa Hung]

Sam Spilsbury wrote:
> Regarding BlurFX and reflection, they used something that avoided the 
> use of pixel shaders (But BlurFX used pixel shaders where they were 
> available). The problem with correcting rendering/ driver problems 
> within Compiz-Core is that they can come and bite you in the back or 
> break something else, because they are *workarounds*.

Is a workaround that troublesome if it doesn't interfere with the code 
paths that would be taken if it wasn't necessary? If a workaround 
requires potentially unstable code to be running regardless of whether 
the workaround is active or not, that may be a problem, but if it's only 
used when it's needed...

Well, at the risk of making another irrelevant analogy ;), fake 
translucency in terminal windows and desktop widgets were perfectly 
acceptable workarounds until recently, and now that real translucency is 
possible, there doesn't appear to be a scramble to remove the fake 
translucency code.

> Yeah, we need to post a list of current functional regressions and what 
> is and what is not possible. (Technically) There is already one on 
> obby.opencompositing.org <http://obby.opencompositing.org> and 
> functional regressions are few and far between.

Nice. ^_^ I have a few things to add.

> I'm not a developer, but 
> I do sort-of know that by adding hook-interfaces to core-plugins, we can 
> actually add these features in separate plugins, instead of destablizing 
> the core plugins. Hopefully, most of these will be corrected soon.

vpswitch, scaleaddon, and scalefilter are ingenious. ^_^ I'm very
pleased to see long-standing issues being resolved in ways that don't
involve directly changing other people's sensitive code. :D

> KWin != problem IMO ;)

Until it stops crashing and starts becoming as customisable as KDE apps 
typically are? :P


~Alyssa