3D [LWN.net]

Posted Jun 18, 2010 15:13 UTC (Fri) by foom (subscriber, #14868) [Link]

There's really no reason why apps shouldn't be able to rely on basic OpenGL features working. At *least* via software rendering, even if you have no 3D hardware. And software rendering should be just fine for doing transition effects for a slideshow. That apps currently cannot reliably depend on OpenGL to work is a big problem...

Luckily, there is a lot of working going on now to fix that problem, so for new apps, I too would be mighty tempted to just assume it works for everyone, or will work soon enough to not matter.

Posted Jun 18, 2010 17:02 UTC (Fri) by drago01 (subscriber, #50715) [Link]

I wasn't being specific to the app itself but there is no reason why apps should pretend that opengl is an optional feature that is "rare".

If opengl does not work that something at the system level is _broken_ not the app that tries to use it.

In fact I consider not using opengl where it makes sense a bug; GPUs aren't just providing a framebuffer where you can directly draw to, they can actually do the rendering, so it is valid to use them for their intended task.

Posted Jun 23, 2010 9:51 UTC (Wed) by ebassi (subscriber, #54855) [Link]

so why does an app to display 2D pictures not work on a machine that doesn't support OpenGL?

you seem to imply a dichotomy between a 2D pipeline and a 3D pipeline that has ceased to exist in modern hardware - and by "modern" I mean something released post-1999.

if you have a GPU - be it a discrete or an integrated unit - all your pixels get pushed through the same pipeline. the great goal of the Linux graphics infrastructure is to make everything as hardware accelerated as possible, which means going through OpenGL - the only open API and specification for hardware accelerate graphics.

not supporting OpenGL on capable hardware (i.e. everything that's at most 5 to 10 years old) it's a bug.

Posted Jun 25, 2010 11:10 UTC (Fri) by robbe (guest, #16131) [Link]

> you seem to imply a dichotomy between a 2D pipeline and a 3D pipeline

I don't think that was implied. One can certainly defend the view that a program rendering 2D objects to a 2D output without (normally) doing 3D transformations on them could limit itself to using a 2D API. Especially if the 2D API is supported by everything your target audience is caring about, while the alternative OpenGL has pretty dodgy support on average.

Whether this 2D API is implemented in HW by a 2D pipeline, a 3D pipeline, or a horde of spice-swigging OpenBSD developers warping spacetime with their giant brains is besides the point.

There are of course arguments for using OpenGL without alternative: simplicity; that the 2D API is too crufty; that shoveling wastage at the proverbial fan will finally create enough of a stink that the OpenGL situation under Linux is fixed for good.

Posted Jun 23, 2010 0:38 UTC (Wed) by dododge (subscriber, #2870) [Link]

I haven't tried this latest gthumb (my system is not handy), but I see in the Clutter README that it depends on the XComposite extension. That can be a problem on multi-head systems.

People with only two displays attached to the same card can get around the problems by using things like NVIDIA's Twinview, which tricks the X server into thinking you only have one display. When you add a second card to get three displays it all falls apart. Twinview doesn't work across cards, so you have to enable Xinerama (or live with not being able to move windows between screens). Enabling Xinerama causes XComposite to be disabled because they're not compatible. Xinerama is supposedly deprecated and replaced by XRandR -- which is compatible with XComposite -- but XRandR also doesn't work with multiple cards and and that capability has been repeatedly delayed for something like 3 years now.

Posted Jun 23, 2010 9:44 UTC (Wed) by ebassi (subscriber, #54855) [Link]

Disclaimer: I am the Clutter maintainer

I haven't tried this latest gthumb (my system is not handy), but I see in the Clutter README that it depends on the XComposite extension. That can be a problem on multi-head systems.

the XComposite extension is optional.

also, I have a multi-head system (two panels, my LVDS and an external monitor) and it works perfectly fine. granted, I'm not using an extension and X server from 1997 but something designed released in this millenium. ;-)

and yes, I'm using Clutter on this system. actually, it's the system on which Clutter itself is mainly developed.

Posted Jun 23, 2010 21:44 UTC (Wed) by dododge (subscriber, #2870) [Link]

> the XComposite extension is optional.

Sounds good, thanks.

> granted, I'm not using an extension and X server from 1997 but something designed released in this millenium. ;-)

My 3-head system is running the current Xorg in Ubuntu 10.04, which still can't do XComposite (or XRandR) properly across multiple cards. It does at least do OpenGL, and windowed applications such as Google Earth are okay. Anything that tries to go full-screen can get very confused or worse yet trigger bugs in the X server, though.

It seems like every new release gets a little bit worse. For example with this latest Xorg the server chokes if you try to configure a 3-1-2 screen layout (so that screen 1 is in the center), which had worked fine for the past 4-5 years. The only person I've heard of managing to get XComposite to work across multiple cards had to use a several-years-old modified Xgl server -- it's never worked in Xorg.