GTK+ Developers Call For Help To Finish Cross-Platform OpenGL Support

jones_supa writes OpenGL support under GTK is getting into good shape for providing a nice, out-of-the-box experience by default on key platforms for the GTK+ 3.16 / GNOME 3.16 release in March. For a few weeks now within mainline GTK+ has been native OpenGL support and as part of that a new GtkGLArea widget for allowing OpenGL drawing within GTK applications. Since that initial work landed, there's been more GTK+ OpenGL code progressing that right now primarily benefits Linux X11 and Wayland users. While good progress is being made and improvements still ongoing to the GNOME toolkit, GNOME developers are requesting help in ensuring other GTK+ backends can benefit from this OpenGL support. If you are using or planning to use GTK+ 3 on Windows or OS X, and you know how to use OpenGL on those two platforms, please consider helping out the GTK+ developers by implementing the GdkGLContext API using WGL and AppleGL.

Comments

Simple and stupid question

[Anonymous Coward]

...from a n00b: why would someone back the GTK stuff instead of Qt?

Re:Simple and stupid question

[NotInHere]

Its good to have choice. If there is none, things like heartbleed or winshock can happen.

Re:Simple and stupid question

[Anonymous Coward]

Its good to have choice.

*cringe*. This vapid meme is tired and endlessly parroted even in contexts such as this where it makes no sense and doesn't answer the question that was posed.

Re:Simple and stupid question

[weilawei]

Why would someone back the Qt stuff instead of GTK?

Let's face it. Some of us prefer GTK over Qt. Get over yourself and your One True Way, Holier Than Thou attitude. You're free to do it how you like, and I'm free to use what I like. Choice is good. And in this instance, it was appropriate.

Re:Simple and stupid question

[Iconoclasism]

There isn't a Qt version of GIMP...

Re:Simple and stupid question

[sunderland56]

Some of us prefer GTK over Qt.

So then *you* help them out.

I'm a OpenGL/Linux/kernel/lib developer, and there is no way on God's green earth that I will contribute anything to Gnome.

Re:Simple and stupid question

[Anonymous Coward]

/me takes notes

Re:Simple and stupid question

[Wootery]

Because both are in use, and benefiting either is valuable.

This is true even if Qt is better than GTK in all respects.

Re:Simple and stupid question

[Anonymous Coward]

Ha! I've found GTK to be orders of magnitude easier to program in than Qt. Frankly speaking, it was a steep slope for GTK, but Qt looked worse (C++ through a preprocessor, evne harder to understand documentation). I tried both, I had a basic program running in two days in C in GTK, I had exactly zero success after 2 weeks in Qt.

Re:Simple and stupid question

[Anonymous Coward]

Why would anyone downvote this simple on-topic question? Some mods are fucking retarded!

Re:Simple and stupid question

[Anonymous Coward]

GIMP is so goddamn awful though so that's a good thing!

Re:Simple and stupid question

[kyrsjo]

Agreed. At least pyGTK is very straight-forward to use, even for someone like me with little GUI programming experience. I can't really speak for QT tough.

Re:Simple and stupid question

[Wootery]

GTK's answer to the Qt's 'MOC' preprocessor is Vala: a whole C#-like language, just for GObject, which compiles to C.

Re:Simple and stupid question

[geminidomino]

Get over yourself and your One True Way, Holier Than Thou attitude

Funny, that's my boilerplate response to GNOME these days.

help them

[NotInHere]

... so that they can focus on fucking up the desktop like with gnome 3?

Re:help them

[Anonymous Coward]

Flamebait upvotes? My, Slashdot has fallen far.

Love it or leave it, without Gnome, there will be a mono culture in the desktop space, and mono culture has always been a bad thing. That's not to mention that a lot of people do like Gnome3, but those who don't tend to not acknowledge that they exist.

Re:help them

[xiando]

GTK+ used to be a general purpose toolkit and it was originally named the GIMP Toolkit. The gtk+ homepage still refers to it as such. It is, in theory, not only for GNOME. The sad reality, though, is that these days the GNOME developers are busy removing features from GTK+ which breaks existing applications, cripples them and removes features from them so in practice it's basically a GNOME toolkit as of right now. That does not mean you can't submit patches to it in order to make it more general-purpose. If this is worth your time is, as you indicate, an open question, though. Like .. what is the point of submitting a patch like "This patch reverts your removal of icons from menu items and puts the icons back in the menus"? I could go on but you get the idea. Many of us have simply decided to stop using GTK+ for development because of their various unacceptable choices and see no point in contributing to this project which has sadly left only GNOME developers to work on it.

Re:help them

[Anonymous Coward]

Monoculture? Which desktop? Metro? KDE? Aqua? Unity? XFCE? What are you talking about?

Re:help them

[Anonymous Coward]

Love it or leave it, without Gnome, there will be a mono culture in the desktop space

How so? In what world is there only a binary choice between Gnome and one other DE? There are plenty of other choices if Gnome were to go away.

Re:help them

[Anonymous Coward]

> Love it or leave it, without Gnome, there will be a mono culture in the desktop space, and mono culture has always been a bad thing. That's not to mention that a lot of people do like Gnome3, but those who don't tend to not acknowledge that they exist.

Name 2.

Re:help them

[weilawei]

How about 23? Look at the gallery for just a sampling.

Re:help them

[Desler]

The "Name 2" was to "That's not to mention that a lot of people do like Gnome3, but those who don't tend to not acknowledge that they exist." It wasn't saying to Name 2 other DEs.

Re:help them

[L-One-L-One]

I fully agree. I like the GTK+ API and I still continue to use it because shifting to another toolkit for my apps would be costly. But I'm loosing patience:

GTK+ development has become an unprofessional mess. Functions get deprecated even with minor version changes: you develop your app with version 3.xx and distribute it. Then people move to 3.yy (where yy>xx) and bang your app does not work anymore because someone decided to *remove* a function from GTK+ without any consideration for existing apps out there. Sometimes the fix involves a new function that does not exist in the previous version of the library, so you can't even find a real fix that would work with all versions from 3.xx and above. You just add some ugly preprocessor macros in your code to deal with different versions of GTK+ at source level...

Re:help them

[AchilleTalon]

Linus Torvalds and I love Gnome 3.

Re:help them

[AchilleTalon]

BTW, it is not about Gnome 3 anyway, it is about the toolkit on which Gnome 3 happens to be based. You probably run some GTK+ based application, even if you use KDE, Unity, XFCE or anything else.

Re:help them

[kthreadd]

An API is not removed just because it's deprecated. It just means that you are discouraged to use that function in new code, and that it *might* be removed in a later version. This is not uncommon in minor versions and you typically wait for a major version until you actually remove them, to preserve ABI compaitibility.

Re:help them

[rl117]

I used to professionally develop GTK+ applications in the mid-2000s. It wasn't excellently maintained even then, but nowadays it's woeful. While it's nominally cross-platform the reality is it's always been in a state of partial brokenness on MacOS and Windows. You couldn't ever truly rely on it for cross-platform work.

I moved completely to Qt over the last couple of years. I still prefer the container model of GTK+, but the quality of the Qt toolkit is so much greater that a minor design difference is neither here nor there. If I was evaluating which toolkit to use for a new project today, Qt would be the default choice; GTK+ wouldn't even be on the shortlist. If I had to propose it for use to the rest of my team, I'd be laughed out of the room, and not unjustifiably.

Looking at the level of OpenGL support with this new work, it looks useful, but quite limited compared with what's in Qt. For example, with Qt the GL context has the ability to select which core profile you want to use and you can subclass your widgets with the GL functions you need to use, saving the need for GLEW or other GL wrappers. And it also has helper classes for wrapping shaders, accessing uniforms, and a whole bunch of other useful stuff which makes using GL vastly nicer than using the raw C API (though this is of course possible). I don't see any equivalent to these facilities in the GTK+ work.

Re:help them

[Anonymous Coward]

I agree wholeheartedly with your view on monoculture. Monoculture is bad, it has always been nd always will be. However, right now, the biggest problem of monoculture in computing is the x86/x64 monoculture. Besides the fact that it is little-endian and I live, breathe and think in big-endian. For me, bit 0 is and can only be the most significant bit of any entity, but I digress.

Re:help them

[Blaskowicz]

Why not use GTK2. That'll teach them lol. At this point it won't go away like Motif and other toolkits?

Re:help them

[Blaskowicz]

I'm curious about what would be above GTK+3 on the list. Tcl/tk, FLTK 1.3 maybe?

Re:help them

[rl117]

Difficult to say, it really depends upon the project, language and portability requirements.

Most of my projects are currently in C++ and/or Python. Qt 4.x and 5.x work well here for both on all current platforms (FreeBSD, Linux, MacOSX, Windows) including OpenGL support for all.

GTK+ 3.x is a non-starter. Its repeated breakage and dropping of functionality make it unsuitable for non-GNOME work (and even for GNOME developers it must be painful, as several of them have commented).

GTK+ 2.x might be a possibility for FreeBSD/Linux-only projects or projects where a subset of GTK+ which works on all needed platforms is actually functional. For anything complex, the chance of cross-platform breakage approaches certainty in my experience.
The GTKmm bindings are excellent but you are still wrapping a C API which introduces constraints e.g. for exceptions and I have run into bugs in the past; this is what the API should have been if C++ had been used from the start. I'd certainly be happy if they dropped the C implementation and made it the base implementation; it would resolve many of the quality issues with the library which are rooted in the inadequacy of OO-C compared with a proper OO language.

FLTK is superficially nice but its odd structure makes making new or derived widgets painful (from memory, not used recently). Certainly a possibility for simpler projects which don't need custom widgets.

wxWidgets is good in concept but fails in execution (it looks out of place on all platforms), and has to be a lowest common denominator in order to work with platform-specific toolkits. My trials showed up lots of widget layout issues if you wanted it to be good on all platforms, but with effort you might be able to make it work better.

GNUStep is a bit too niche for me to have tried using it in anger; last time I looked a decade back it was not completely compatible with the modern MacOS X evolution of OpenSTEP and required use of Objective-C. I wasn't sure it wasn't an evolutionary dead end at the time, and I'm not sure now.

Tk seems like a nice toolkit which has kept going over time and which does seem to work on all major platforms without too many major headaches. I'd certainly consider it if using a compatible language and didn't need the heavyweight widget and other libraries from Qt.

So I think very broadly I'd go with Qt > Tk > FLTK > GTK+2, though which would be most appropriate would depend upon the project.

Regards,
Roger

Re:help them

[devent]

How abou Swing/Java or JavaFx?
IMHO it beats all the C/C++ stuff, is cross-platform and have a bunch of open and commercial widget libraries. And, with Eclipse or Netbeans, and maven you have much better developing tools that are free, and you don't have to compile anything.
With jogl or JMoneyEngline you can access OpenGL if you need.

Re:help them

[Gibgezr]

He uses C++ and Python. Why in hell would he stoop to Java? You don't meet many experienced C++ programmers who want to spend their days using Java instead, now, do you?

Re:help them

[kyrsjo]

Yeah. Ususally the only bad thing is some warnings in the terminal that "XX is depreciated"

Re:help them

[ultranova]

You don't meet many experienced C++ programmers who want to spend their days using Java instead, now, do you?

You don't meet many people who want to work with tools other than what they're used to, in any field.

Re:help them

[rl117]

They completely passed my mind while writing my reply. While I do have quite a lot of exposure to Java and Swing at work, I'm afraid to say my experience is not hugely positive. For the applications I maintain, the default (metal) look and feel on Linux is awful, though some distributions do replace this. While it certainly does work on all supported platforms, I'd have to say that I do prefer Qt by far, since its native look and feel is almost perfect on all platforms in my experience, and performance also enters the equation once you start doing OpenGL stuff, if not before. Stuff like jogl also uses JNI and this also affects platform support--needing to ship the native parts compromises the portability since you restrict the platforms you can deploy on. I do think that it's less effort, more robust and gives better platform coverage to build natively. Building the JNI wrappers for every platform is doubtless possible given sufficient effort, but a pain to build, integrate and test. Last time I tried to build this from source it turned out to be impossible; I do have concerns that the mess of dependencies that maven drags down is not independently rebuildable, and that's not even getting into the security concerns.

Re:help them

[Gibgezr]

Touche. If I was a web developer working with all those nifty Java class libraries for doing webby things, I wouldn't want to use C++ either.

Re:help them

[devent]

I have a very positive opinion of Metal L&F, I use VisualParadigm and FreeMind, both are Java applications. I don't think that the L&F matters as much as people always say. The performance of Java apps is on par with C/C++ and Maven is a huge win, because I can use just any lib that I want and the dependencies are automatically resolved. Much like the package manager on Linux. And that I don't have to compile anything is also a huge win, it's was always a pain to compile C/C++ applications.

Any OpenGL lib will be platform dependent, so I don't think your point is valid.

"I do have concerns that the mess of dependencies that maven drags down is not independently rebuildable, and that's not even getting into the security concerns."

I don't understand what your concern here is. Maven is like the package manager from Linux, and the whole point of maven is to be independently rebuildable.

Ob

[Hognoxious]

Would love to, but I'm busy writing a combined init system, web server & tic-tac-toe engine.

Re:Ob

[wonkey_monkey]

The only winning move is not to boot.

Re:Ob

[fibonacci8]

Emacs users never fail to surprise me.

Re:Ob

[Anonymous Coward]

Would love to, but I'm busy writing a combined init system, web server & tic-tac-toe engine.

Seems like the ideal place for a userspace opengl stack.

Just use SystemD

[Billly Gates]

It does everything

Re:Just use SystemD

[Anonymous Coward]

Not everything. SystemD still lacks a good, stable and easy to use init system.

AppleGL?

[Anonymous Coward]

Referring to it as WGL and AppleGL shows an astounding level of platform ignorance.

Re:AppleGL?

[BitZtream]

WGL and AGL are the Windows and Apple (respectively) are the glue APIs that allow you to setup and work with an OpenGL context and surfaces.

You can't render OpenGL commands using the native drivers without first setting up an OpenGL context with these APIs.

The ignorance here is that you know so little about programming, and OpenGL in particular that you don't realize that AS PART OF THE SPECIFICATION, EVERY OS HAS THESE LAYERS between native windowing system and platform independent OpenGL API.

For X11, you might have heard of ... glx ... Which is the equivelent.

Re:AppleGL?

[Anonymous Coward]

Uhm...reading comprehension problems?

The GP poster was making a cheap shot at systemd's propensity for extreme features creep...something that Lennart's VERY guilty of. (What in the f*ck was Red Hat thinking giving that man a job? Seriously...)

As for the rest...I can't grok that they need "help" to finish it. It should be straightforward. Implement the damn stuff using the Red Book explicitly as a guide, use things like buffer objects instead of immediate mode commands, and just simply implement the damned thing.

Once they've done that, you only really need to, as you rightly observe, set up the context using the platform commands (which includes EGL in the case of GL ES 2.x systems...) and just simply go. It literally bolts on top of ANY platform that properly implements the spec. Code it. Code the thin enablement shims. DONE.

This isn't that big a deal- and they shouldn't be attempting OpenGL support if they can't manage that little and simple a thing. Seriously.

Re:AppleGL?

[Desler]

WGL and AGL are the Windows and Apple (respectively) are the glue APIs that allow you to setup and work with an OpenGL context and surfaces.

There is no such thing as "AppleGL". There is AppKit which contains classes to set up the OpenGL contexts and surfaces and GLKit for constructing textures, etc.

Re:AppleGL?

[Anonymous Coward]

The thing is...AppKit is the equivalent of WGL and GLX on Apple, hence, "AGL"... SMH, you're pretty damned stupid to have went on like that- but I'll bet you didn't know that. But then, this *IS* /., after all...filled with screaming electronic poo flinging monkeys...yourself included there.

GNOME toolki? nope GIMP Toolkit

[xiando]

GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. http://www.gtk.org/

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

Embrace-ed by Gnome.
Extend-ed to require Gnome+systemd as hard dependancies.
Extinguished, soon enough.

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

is a multi-platform toolkit

Meaning it once supported GNOME 2 and now supports GNOME 3. There was a nice presentation on one of Linus open source projects migrating to Qt since nobody in the Gtk community gave a shit about support in general and Windows support in specific. They put a C++ UI library on top of a pure C code base because Gtk is just that bad an alternative.

Re:GNOME toolki? nope GIMP Toolkit

[kthreadd]

Well, except that in this case the entire story is that they want help making it work great on non-Gnome platforms.

Re:GNOME toolki? nope GIMP Toolkit

[kthreadd]

According to the story you just commented on they apparently care quite a lot about cross-platform support since they want people to help them with it.

Re:GNOME toolki? nope GIMP Toolkit

[MrEricSir]

Actually, GIMP still uses GTK+2.

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

gtk2 did... then gnome devs went on a remove fucking everything spree and now noone except the gnome folk wants to use it.
gtk should rename itself to gnome tk and die with gnome.

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

More like Gay ToolKit.

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

As does the Linux kernel's `make gconfig` target.

Re:GNOME toolki? nope GIMP Toolkit

[Anonymous Coward]

For a group as large as GNOME it is rather telling that they have no one with the required skill-set at hand, it also makes for a bad cross platform API when you code against your platform of choice (Linux) and then give that platform specific mess to someone else to port it. Right now all they did is tell everyone that it is open source and if you have to write the code to make it work for you anyway you might as well give it back to GNOME. I can clearly see how motivated they are about being cross platform. Just as motivated as when Windows support was just an unsupported hack - wait it still is.

Patch in progress for Quartz/Mac OS X

[brion]

Started on this last night, but I'm not super familiar with the OpenGL details on OS X either. Help with scaling and fixing the painting welcome. https://bugzilla.gnome.org/sho...

Help Redhat's hostile takeover of Linux?

[walterbyrd]

No thanks.

These days: Redhat == Microsoft.

I am surprised that more people don't see that.

Re:Help Redhat's hostile takeover of Linux?

[Anonymous Coward]

Oooh! Look at the whining luddite! Butthurt over systemd much?

Re:Help Redhat's hostile takeover of Linux?

[Anonymous Coward]

Considering that systemd's being written by someone that's presided over two other kludges that were looking for the problem to solve that never QUITE got there, yeah....if that's "butthurt", I am.

We need something other than sysv init, yes. Systemd in it's current form isn't it.

The fact that Red Hat's basically jamming this homesick abortion down everyone's throats for all intents and purposes doesn't really endear them to many right at the moment- myself included.

Re:Help Redhat's hostile takeover of Linux?

[Anonymous Coward]

Your mom == microsoft

Re:Help Redhat's hostile takeover of Linux?

[Anonymous Coward]

Yeah, like everyone had her, but then dumped her due to bugs, viruses, and other bad stuff.

thanks. I can only test

[raymorris]

Thanks for your work on that. I'm npt familiar with graphics programming at all since my work always uses either a cli or browser-based GUI, but I do have some Macs around for testing and such.

Already been done.

[Anonymous Coward]

Just do a wrapper for this.

If you are using or planning to use GTK+ 3...

[Anonymous Coward]

If you are using or planning to use GTK+ 3 on Windows or OS X, and you know how to use OpenGL on those two platforms, please consider helping out the GTK+ developers by impl...

And there you go, nobody uses it for Windows or OSX, the most feature-complete, usable, multiplatform toolkit is Qt.

Heck, less and less people are using it on Linux, that's why they have such a lack of developers. Can you see it now? You've fucked up GTK+

Qt...

[Tough Love]

Need I point out that QT has had cross platform OpenGL support for many years? In QT, this is mature, reliable, well integrated and easy to use.

Re:Qt...

[sfcat]

Couldn't agree more. I spent 3 years writing an OpenGL app using GTK+. I just spent the last 6 months porting it to QT. And even with having to using C++ in places in the code (I wanted it to be pure C) I couldn't be happier with QT. And I probably couldn't be less happy with GTK+. When I finally got the GTK+ version working on windows, it had terrible performance. GTK+ is a total mess developed by people with no desire for you to use their code. For years the GTK+ devs actively questioned the usefulness of supporting OpenGL and refused to even answer questions about the OpenGL support. The devs are openly hostile to things like OpenGL and they break compatibility on a regular basis. The QT version of my app's code has probably 30000 fewer lines due to far more sane APIs and much more useful widget APIs. Why anyone in this day would use GTK+ for anything unless they were required to use only pure C in their app is beyond me.

Re:Qt...

[luminousone11]

Does QT use xlib or xcb under the hood on X11 based systems. I ask because I would like to thread applications without worrying about the finicky nature of xlib when threading is involved.

Re:Qt...

[sfcat]

Does QT use xlib or xcb under the hood on X11 based systems. I ask because I would like to thread applications without worrying about the finicky nature of xlib when threading is involved.

I'm not 100% sure but I think xlib. xcb is mostly dead these days, or so I get that impression. I really wish xcb had more traction but only a few apps need this type of multi-threaded GUI functionality (my app being one of those few) so it seems to get left behind.

Re:Qt...

[Anonymous Coward]

Qt5 uses xcb. The platform plugin for X11 is even called... drumroll... qxcb.

Qt4 uses Xlib.

Re:Qt...

[strikethree]

I like your .sig

"Those that start by burning books, will end by burning men."

Where is it from?

Disgusting

[Anonymous Coward]

I said: Guys, don't go OpenGL with Gnome3.
GnomeDevs said: We'll go OpenGL, it's the future.
I said: Guys, plz! That's stupid. OpenGL on Linux isn't in a good shape, if avaible at all.
GnomeDevs said: No, we do Features! OpenGL is needed for that. Why do you hate the future of Desktop?
I said: Guys, stop plz! I rather have a fast Desktop than a shiny slow and buggy one. Can't you make your OpenGL features optional? I mean, like basically a fast lean Desktop and the "new shiny features" can be turned on if the driver and hardware can handle it?
GnomeDevs said: No stupid Troll, that's stupid! Go away! OpenGL is future, why you hate future? We require OpenGL, don't use it if you hating much.
I said: Goodbye Gnome.
GnomeDevs said: Bye! ;-)

----Today----
GnomeDevs said: HALP! Can we has OpenGL plz? We stupid, we can't do it.

Bring out the Krita

[tepples]

What's wrong with Krita?

Re:Bring out the Krita

[Anonymous Coward]

Nothing.

Re:Bring out the Krita

[HiThere]

Well, I haven't tried it in a few years, but the last time I found it intensely horrible, to the extent that it was unusable. OTOH, for most of what I do I prefer Inkscape over the GIMP.

Re:Bring out the Krita

[Anonymous Coward]

Well, I haven't tried it in a few years, but the last time I found it intensely horrible, to the extent that it was unusable. OTOH, for most of what I do I prefer Inkscape over the GIMP.

If you haven't tried it "in a few years" then your experience is irrelevant and you shouldn't have commented. Try these on for size:

"I haven't tried Windows in a few years, but the last time, I found Vista intensely horrible, to the extent it was unusable."
"I haven't tried KDE in a few years, but the last time, I found KDE 4.0 intensely horrible, to the extent that it was unusable."
"I haven't tried GNOME in a few years, but the last time, I found GNOME 2.x to be pretty good"

A few years for software can be huge, which is the case with Krita. Yeah, it was a dog a few years ago, but the experience now is so far removed from what it was that it's practically a difference program. Stability is usually good, it's gotten a lot of nice features lately, and a lot of work has been done on performance too, with a lot of emphasis on the GL-accelerated canvas. It also has some things gimp still hasn't gotten right, like support for high bit-depth and non-RGB images, and some non-destructive layer operations.

I like getting the new features that come in and hate waiting on Debian (testing) to get the updates, so I follow a testing build that one of the devs supplies via PPA. Even doing that, it's usually pretty stable, and the actual stable versions are even better in my experience.

It's much nicer to use than gimp these days, so it's worth giving another try. Biggest problem is that it's targeting a different use case than gimp, so while there's a lot of overlap, each program has different strengths.

Re:Bring out the Krita

[grumbel5969]

In terms of features Krita is great, but it's also very slow and sluggish. Just doing basic stuff like scrolling the view around makes it use 100% CPU and render at like 5FPS, even on a trivial single layer image. This sluggishness makes it not very fun to work with and it has been that way for years.

Re:Bring out the Krita

[Anonymous Coward]

In terms of features Krita is great, but it's also very slow and sluggish. Just doing basic stuff like scrolling the view around makes it use 100% CPU and render at like 5FPS, even on a trivial single layer image. This sluggishness makes it not very fun to work with and it has been that way for years.

That's only true if you're using it without OpenGL acceleration enabled, which you should only do if you can't enable it for some reason. More recent versions enable it by default I think. Like the other guy above you're trashing a program based on an outdated experience. (GL canvas acceleration has been around for a couple years)

Re:Bring out the Krita

[tepples]

Thanks for giving us a serious and informative answer. What OpenGL version does the driver have to support in order to get a GL accelerated canvas in Krita? I know WebGL doesn't work in Firefox on Intel GMA 3150 because its driver only supports OpenGL 1.4.

Re:Bring out the Krita

[Anonymous Coward]

I don't know what the minimum OpenGL version is, unfortunately. A quick search shows that it got revamped sometime last year to support newer OpenGL 3.1 and GL ES 2.0, but I don't see anything stating that 3.1 is the minimum.

Launching newer versions of Krita from the terminal and opening or creating a new document shows that it does an incremental check for OpenGL support, like so:

use opengl true success "OPENGL_SUCCESS"
OpenGL version 1.1 or higher is present.
OpenGL version 1.2 or higher is present.
OpenGL version 1.3 or higher is present.
OpenGL version 1.4 or higher is present.
OpenGL version 1.5 or higher is present.
OpenGL version 2.0 or higher is present.
OpenGL version 2.1 or higher is present.
OpenGL version 3.0 or higher is present.
OpenGL version 3.1 or higher is present.
OpenGL version 3.2 or higher is present.
OpenGL version 3.3 or higher is present.
OpenGL version 4.0 or higher is present.

So it's possible that it just enables different features depending on what version of OpenGL you can use instead of an all-or-nothing approach. Kwin does the same thing so it's not too unlikely. I was able to use OpenGL mode on my laptop, but two caveats: 1. it has an older version of Krita that may be from before they added higher version support, and 2. the laptop supports GL 2.1, which makes it a poor comparison unfortunately.

One thing I've noticed while checking this: the Linux version still works pretty well even without acceleration enabled. Rotation is horribly slow, but panning is tolerable and things like brush strokes are fine. I've heard the situation is more dire in the windows builds and that OpenGL support is practically mandatory there for it to be usable, but I haven't had to deal with it myself so I can't confirm the statements.

Probably the best thing to do would be to install it and try turning on the GL acceleration and see if it works or not. I know that's not a particularly useful answer, but I'm not a dev or anything so I don't know much about its internals. I just use Krita and occasionally try to answer questions people have about it. If you have any other questions I'll try to answer them as best I can.

Re:Bring out the Krita

[Anonymous Coward]

Followup about the OpenGL versions. I decided to upgrade the laptop to Jessie since it's in freeze, which means I got a more recent Krita build with the newer OpenGL code. The console output does the same incremental version check, stops at 2.1, and it still gets the accelerated canvas features.

I did notice that it's missing one of its high-quality filter setting options for the scaling mode, so that means Krita is just adding/removing features based on what's supported for each OpenGL version. That's a good sign for getting the accelerated canvas even with a driver that only supports OpenGL 1.x.

Sorry GTK

[DMJC]

Sorry GTK/GNOME, but I am done. I'm fed up with trying to use your API. I'm fed up with trying to shoehorn my systems to fit your paradigms. All I want to do is make a Linux version of a tool I had on Windows, but you won't let me focus on that. Rather you want me to make some weird touch centric/single display centric application which I have no wish or desire for. I am going to move to GNUstep. Yes the API doesn't shift quickly. But I consider this a good thing. An API that for 20 years has allowed users to choose Apple menus, windows menus, or NextStep style menus. There's a lot of freedom and choice in a platform that let's the user decide the UI paradigm they want to use, and which doesn't ram their paradigm of choice down your throat. I am also moving to an api that is inherently cross-platform from day one.

Re:Sorry GTK

[Anonymous Coward]

You can do that with GTK+! You can use window menus, application menus or GtkMenuButton menus.

Re:Sorry GTK

[HiThere]

GNUStep is very interesting, but every time I've tackled it, I've bounced. Sometimes I literally couldn't figure out how to do things, other times it's just that it was too difficult to bother.

They *REALLY* need better documentation. Probably the toolkit is fine. Every time I worked at it long enough I was able to make it do what I wanted, but the documentation is truely terrible. And it needs to be written by someone who already understands the system.

If the GNUStep documentation had been better, I'd probably be programming in Objective C today. (Well, maybe not, I tend to switch between languages a lot. But I would have used it significantly.)

Fuck GTK-. I'm off to Qt

[Anonymous Coward]

Fuck GTK-
I'm off to Qt

Cross Platform?

[Anonymous Coward]

Not sure how developers dare to say that anything related to Gnome is 'cross-platform'.