Re: Request for removing clutter in current form

[Emmanuele Bassi <ebassi gmail com>]

On Sun, 2009-08-16 at 12:12 +0200, Maciej Piechotka wrote:
> I'm sorry I'm posting it on wrong list.

yes, you probably wanted to mail to desktop-devel-list instead of
gnome-devel.

> I'm usuing currently Gnome 2.27.x and I've become worried about new
> dependency - clutter.
> 
> OpenGL traditionally have been problematic on GNU/Linux, not mentioning
> other *nixes. Many cards are only partially supported and/or produces
> not exactly correct results. Proprietary drivers not only are
> proprietary but often are not stable. 

that *was* mostly true. the majority of GPUs, nowadays, work fine on
Linux with open source drivers[1], and provide the basic functionality
that Clutter requires[2].

> Unfortunately I have rather old and strange ATI card and OpenGL I can
> best describe as 'sometimes' working. If an game uses it I'm prepared to
> have blinking screen or artifacts (I'm using 2.6.30.4 kernel but
> problems was 'since always'). I don't use propertary drivers since it
> tended to crash computer. While recently situation improved much I guess
> that many users may have similar problems.

> When I tried new clutter-based gnometris I haven't see it running at
> all. The main portion of screen was the previous background. While I
> understend that it is not a gnome bug it shows that OpenGL is not
> perfect even on 'geeks' desktop. 

well, I wouldn't agree on the definition of your desktop as the
paradigmatic 'geek' desktop -- my puny 945, which is three years old and
that is commonly found in netbooks nowadays, is perfectly fine when
running gnome-shell *and* GL applications inside it. older cards, like
the 855 (which was released in 2003) have more problems, that's true.

as for ATi cards, I'm pretty sure that the open source drivers have
become a lot better than the closed source ones; we test Clutter on
Intel, ATi and nVidia cards to check for issues -- obviously, it's
informal QA for ATi and nVidia, so we cannot possibly say "we support
every driver/GPU/operating system combination ever"; that's why we rely
on bug reports to know what degree of support we can provide.

> While I understend the need of eye-candies I'd be rather grateful if
> features would not be hard-depended on OpenGL - since it is not working
> everywhere - especially rather old/new/peculiar computers.

I don't think you'll like the plans for GNOME 3.0 to use GNOME Shell,
which is based on a composited window manager using Clutter, then. :-)

I understand the objection to the introduction of a feature that heavily
depends on hardware and drivers. it's true: if the hardware support is
lagging behind then it's always a pain.

I'd like to point out, though, that innovation cannot be driven by
looking at the past; if GNOME, and the Linux desktop, want to be
relevant with the users of today and tomorrow it cannot still be
anchored to hardware requirements of 5 to 10 years ago. if desktop
environments like GNOME don't push for resolving the drivers gap that we
have with Windows and OS X, by making use of features that desktops,
laptops, netbooks and embedded platforms *right now* expose, then the
Linux desktop won't ever be relevant.

so I hope that you believe me when I say that I'm very sympathetic with
your issues. on the other hand, it's not like GNOME is requiring a
change of Windows Vista proportions: you need a GPU that has open source
drivers and was released between five and three years ago to have a
decent, modern, hardware accelerated desktop.

ciao,
 Emmanuele.

+++

[1] at least, Intel GPU and ATi GPU have gotten better; nVidia GPU
support through the nouveau drivers is the default in Fedora 11, and
while it's not at the same level of the proprietary drivers, it has
grown remarkably since the beginning of the project.

[2] Clutter does not require an extensive support for OpenGL; we don't
use (yet) shaders, and we try our best to be efficient. the work that
has been done during the 0.9 development cycle was all geared towards a
better use of the GL state machine to avoid too many changes and
increase performance.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi