Created attachment 53528 [details] Left: the new oxygen.so - Right: the SUSE's older oxygen.so enforced Version: unspecified (using KDE 4.5.3) OS: Linux This code (inserted at hellowgl demo window.cpp): QHBoxLayout *mainLayout = new QHBoxLayout; QFrame * frame = new QFrame(this); QHBoxLayout * frameLayout = new QHBoxLayout; frameLayout->setContentsMargins(0,0,0,0); frame->setLayout(frameLayout); frame->setFrameStyle(QFrame::StyledPanel|QFrame::Sunken); frameLayout->addWidget(glWidget); shows 1pixel rubbish around glWidget with the oxygen-style shipped at Maverick. I've substitued the /usr/lib/kde4/plugins/styles/oxygen.so by openSuSE 11.3's one and, then, the display is just correct. With the newer oxygen.so (Maverik and/or kubuntu-ppa's) despite of the rubissh the glwidget is pushed to a higher margin than expected; rubish dissapears using large enough margins (about 7 pixel). With the older oxygen.so, the glWidget gets tightly close to the frame bounds (about 1 pixel due to frame rounding) and there is no rubbish and the visuals are correct Reproducible: Always Steps to Reproduce: Just modify hellowgl example to insert an styled panel sunken frame where to place the glWidget, and set the layout margins to 0 (or anything lower than 7). The code posted above would suffice. Actual Results: The glWidget is drawn, but there is a zone between the frame and the glWidget where there is rubbish; resize the window if you don't see the rubbish on first time. Also, the margin used is not the specified one: this is clear when specifying 0 margins. Expected Results: Tighter glWidget to the frame and no rubish (as it happens with the oxygen.so from SuSE 11.3's (compiled with Qt 4.6.3, but I am using directly Qt 4.7 here and surprisingly the oxygen.so does not crash even I have only subsituted the oxygen.so and nothing else) I recall same kind of problems with the Bespin style time ago (I decided to uninstall bespin and never tried since then). Behaviour in lucid was just fine. Behaviour in OpenSuSE 11.3 is just fine. Behaviour with oxygen-transparent is also wrong. With raised frames rubish does not happen. With panel style there are not problems. I've no seen problems with other styles (plastique, polyester, qtcurve have round corners at the styled frames and do not show this problem). It seems something restricted to styled sunken panels in oxygen style. The attachment image shows what it is wrong and how it should be.
Qt or driver problem.
(In reply to comment #1) > Qt or driver problem. It could be, but note that when running older oxygen.so in the same system the problem disappears.
Hi, I'll have a look ASAP. Questions: 1/ "older oxygen.so": how old ? From kde4.4 ? 2/ how does the same example behave with skulpture. I'm asking because I suspect an issue with the re-implementation of the sunken frame shadows (from kde4.5), that are now rendered using a separate transparent, and overlapping, widget in a way that is similar to skulpture. Hugo
(In reply to comment #3) > Hi, > > I'll have a look ASAP. > > Questions: > 1/ "older oxygen.so": how old ? From kde4.4 ? > 2/ how does the same example behave with skulpture. > > I'm asking because I suspect an issue with the re-implementation of the sunken > frame shadows (from kde4.5), that are now rendered using a separate > transparent, and overlapping, widget in a way that is similar to skulpture. > > Hugo Hugo, quick answers: 1/ About KDE at the SUSE machine says: Platform Version 4.4.4 (KDE 4.4.4) "Release 3" 2/ skulpture behaves just fine (but the dropshadow is not seen because gets behind the widget, which is not a wrong thing afterall). I've modified the 2dpainting example in the same way, and oxygen does fine for the "native" widget but messes again the margins and the surrounding of the opengl one. Skulpture behaves exactly the same at both widgets (drop shadow effect is hidden by the both widgets). Oxygen stops pushing rubbish after a few resizes in this case, but the margins are different between native and opengl widget.
More info, With the 2dpainting style and xmag, I can see that the new oxygen.so does modify slightly the "native widget" close to the border, darkening a bit 1 pixel (because that zone seems to be part of the decoration of the frame IMHO). The older oxygen.so does not, as if that was drawn behind the widget. Hope this info is insightful.
at comment #5: yes, thats exactly the point of the rewrite mentionned in #3: the new shadow extends above the frame contents (as a real shadow would do), which is achieved by this additional transparent shadow widget. (makes sense ? Note that the same is achieved in lists, with and without hover). This is why I think Christoph might actually be right: some (driver/qt) bug about painting a semi-transparent widget on top of a GlWidget. But I'll run some tests on my side :)
I appreciate your rapid answers and your interest :) About the driver/qt bug, for the record, I'm using nvidia drivers. I've been playing with the 2paiting example, and it seems to confirm what you are saying. It is not the glwidget gets a bigger margin: what it happens is that the zone where the shadow should be overlaid to the glwidget gets corrupted. Resizing the window enough, both glwidget and "native" widgets do have the same size. I'm attaching an image to show this.
Created attachment 53543 [details] New oxygen.so. Left: without resizing. Right: after the window has been resized
Hmm, Xnest (poorly) and Xephyr show the same problem in my system. It could be something related to the libOpenGL which if I'm not wrong it is diverted by the NVidia driver package installation. I'll keep on investigating.
Additional related info: Overpainting example works OK itself but suffers of the same problems when putting the widget inside a frame (in that case, it is worth noting that the bubbles are not painted at the shadow zone just as the rest of the OpenGL stuff).
Created attachment 56909 [details] Example project demonstrating the issue This example project demonstrates the issue by showing a QGLWidget in a QTabWidget in 4 different configurations. The ones on the left are with documentMode disabled and the ones on the right are with documentMode enabled. The ones on the top do not have a frame while the ones at the bottom have the QGLWidget contained in a QFrame. I have confirmed this problem with the Oxygen style in KDE 4.5.x and KDE 4.6.
Note that this problem does not occur with some other styles (e.g. qtcurve, plastique, gtk, cleanlooks, windows) as can be seen by adding the -style option to command line arguments (e.g. -style plastique) when running Qt-based or KDE-based programs.
Seems to be independant of X server or graphics drivers as it occurs with Cygwin/X, Xming X servers and with Mesa (software rasterizer), ATI, Intel and NVIDIA graphics drivers.
@Jonathan, thanks for the code snipset. Basically it shows that Qt can't paint any widget on top of the GL widget (which _is_ either a Qt or a driver/Gl bug). No other style does that, which is why only Oxygen triggers it. Now: I can probably fix the first 3 issues. (there should be no need to render the tabs on top of the contained widget. I will not be able to fix the last one: the guilty overlapping widget is the inner shadow of sunken frames; it is meant to overlap with the content.
(In reply to comment #3) > 2/ how does the same example behave with skulpture. Hugo, I'm seeing that skulpture seems to draw the shadow beneath the widgets handled by the frame. This works fine if these do not set the background (as it is the usual case) and has no problems for QGlWidgets (despite of that the shadow is not shown, as these definitely draw the background). I guess this is what oxygen style did at the older versions.
Created attachment 61701 [details] Skulpture style behaviour This shows two labels at a styled-panel sunken frame without margins. Left label is opaque whereas right one is translucent. Only the translucent shows the shadow.
Created attachment 61702 [details] Oxygen behaviour Same labels than for the Skulpture case. Oxygen is smarter since the shadow is now present at the opaque label. However this causes trouble when instead of the label, a QGLWidget is used.
OK, I've found a sort of ugly yet effective workaround. My findings have shown me that the shadowing stuff is setup by the polish() process of the oxygen style. So the idea is to unpolish() the frame. What I do, then is to define the showEvent() at my subclass of QGlWidget, and there, do something like this: void myGLWidget::showEvent( QShowEvent * e) { // Workaround oxygen style if( style()->objectName().contains("oxygen") ) { QFrame * frame = qobject_cast<QFrame *> ( parent() ); if( frame && frame->frameShadow()==QFrame::Sunken) { style()->unpolish(frame); } } } It is worth noting that the check is quite weak (but fine for me) and that layout margins need to be adjusted (since unpolish() will undo the offsetting() that polish made because of the frame rounded borders). I think that Oxygen::SunkenFrameShadow should be somewhat aware of QGLWidget (perhaps making QGlWidget able to do overpainting with less trouble in first place). Nevertheless I fail to understand the real thing that it is going on so this idea may be just a dumb one.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!