| Summary: | [playground] GL Applet errors with misleading text | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Ryan P. Bitanga <rjpbitanga> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | zack |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | extend the checks and make sure the other constructor uses them as well | ||
|
Description
Ryan P. Bitanga
2007-12-09 07:57:48 UTC
zack: could you comment on this when you get a chance? thanks. Same problem here (using fglrx). Its the QGLPixelBuffer that has problems. Just a little addon note: QGLPixelBuffer::hasOpenGLPbuffer() return false here (fglrx). This should probably be checked in GLApplet::Private::init() ? The code all those examples (assuming bluemarble just uses glapplet and doesn't do anything stupid) is exactly the same so if one of them just works the others should as well. Having said that, the number and size of supported pbuffers is implementation dependent. We're using pbuffers inside glapplet because the only Qt paintdevices which are capable of creating hardware accelerated GL contexts are qglwidget and qglpixelbuffer. In future Plasma/Qt should have the ability to create a GL context per-executable. This way every applet wouldn't have to create it's own qglpixelbuffer (which are very heavy-weight objects) and be able to use qglframebufferobject. I'm assuming fglrx has either - a nasty bug in pbuffers related code, - a really low limitation on the number of created pbuffers, - fglrx ships with its own libglx and users are mixing it with the stock distro libglx causing those weird mishaps. The bottom line is that the fact that this is with proprietary drivers makes it an uninteresting problem to be honest. The below attached patch should at least make it more consistant in its behavior, feel free to do whatever you want with it Created attachment 22428 [details]
extend the checks and make sure the other constructor uses them as well
Exactly the Problem here. Using the free Radeon Driver on a Ati X800. I dont think it is a fglrx problem. Sadly i cant post a console output cause i don't know how to start plasmoids by Konsole. Maybe somebody could tell me how to do it. What is "Exactly the Problem here"? Test GL Applet 2 doesn't work and Test GL Applet works? If they both don't work then that's the correct behavior. The Open Source drivers don't have real support for accelerating pbuffers. Yes the Test GL Applet works. And the Test GL Applet 2 and blue marble don't work. But if the the open source drivers don't have support for accelerating pbuffers i can live without GL Applets. Just thought it is a plasma bug. Even after applying the patch, the plasmoids behavior is unchanged. Sample GL applet _still_ works. I find it odd and I haven't been able to isolate the cause. Strangely enough, I have also tried linking against the mesa libGL with no change in results. I have verified that both Sample GL Applet and Test GL Applet 2 link against the same libraries. If it's not limited to the fglrx drivers, we probably need to place a note to ATI card users that GL applets are not expected to work with their cards. fgl_glxgears runs fine alongside the sample GL applet, so I'm guessing it's a "only a limited number of pbuffers are allowed" problem with fglrx. I'll try recompiling Qt instead of using the stock Qt 4 provided with Gutsy to see if there is any difference. Is there any chance this could be a Qt bug instead? so things are doing exactly what they are expected to do given the limitations of drivers .. this is not a bug in plasma and the checks have been made a bit more rigorous. closing. |