hi; On 18 August 2014 19:49, Colomban Wendling <lists....@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
