[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Desktop performances (was: Re: GTK+ scene graph)
From:       Emmanuele Bassi <ebassi () gmail ! com>
Date:       2014-08-19 10:47:38
Message-ID: CALnHYQHTymSms=hORh07putpUAUCLFzruiCvdyHqF79QB26vrQ () mail ! gmail ! com
[Download RAW message or body]

hi;

On 18 August 2014 19:49, Colomban Wendling <lists.ban@herbesfolles.org> wrote:
> Hi,
>
> Le 18/08/2014 19:55, Emmanuele Bassi a écrit :
>> [...]
>>
>> when we introduced GL in the pipeline through the compositor 5 years
>> ago, stuff that was 5 years old *at the time* already could run
>> decently.
>
> Not completely, no.

yes, completely, in terms of hardware capabilities. when it comes to
driver capabilities, the only way to improve the situation is actually
*fixing* the drivers, not ignoring the issue and hope that this fad of
multiple dedicated CPU and GPU cores for separate tasks is going away,
because it's not.

the drivers landscape has dramatically improved in the last 8 years,
and that happened because projects outside of the random game port
started relying on these features. well, the drivers landscape has
improved even more since people started porting games as well. the
clear commonality is that, if people needs it, stuff gets fixed.

>  I had (and still have) a really decent '07 card
> (non-integrated 6600GT on a desktop) that always was largely sufficient
> for everything I wanted -- desktop, development, multimedia, even most
> 3D Linux games would run smoothly.  It worked like a charm for
> everything when I ran non-compositing WM (I used GNOME2/Metacity at that
> time), and it was able to perform accelerated video decoding through
> VDPAU, which was very nice as my CPU of that time couldn't really cope
> with full-HD decoding -- and my current one is just barely able to keep up.

that seems to be an issue in the compositor, or again in the drivers.

> So even though compositing WMs looked like a nice idea originally, I'm
> really not convinced anymore (or at least the X11/mutter impl is wrong,
> I didn't try anything else seriously).

desktop compositing is the only way to provide you with a correct,
reliable, and possibly not resource intensive environment. that's why
everybody else, like Apple or Microsoft, has spent years improving
their graphic stack and display servers in order to implement this
functionality. that's one of the tenets of Wayland as well, since we
finally have a sporting chance of not having a joke acting as our
display server.

in any case, we digressed considerably from my original point, which
was using hardware acceleration to draw applications — which is not
even entirely correct: the plan is to use OpenGL to do compositing of
image surfaces inside the application (except possibly for videos, in
which we should use Wayland subsurfaces mapped to hardware overlays in
case they are available), because that's the only API that we can
actually rely on, until we have a better API shared among vendors.
whether that API is actually implemented in hardware or in software I
don't particularly care. if you *do* care, then feel free to start
contributing to Mesa and to the free software drivers stack, instead
of asking for GTK+ to continue down the path of irrelevance because
you conjured out of thin ait a hard requirement for it run on a single
core machine from 2004 with a Matrox G200 card as fast as it can on a
quad core machine from 2014 with an nVidia discrete GPU.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]