Version: (using Devel) Installed from: Compiled sources OS: Linux When editing a text area in a form, white zones (rectangles) appear and cover parts of the text, depending on the position of the cursor. Also scrolling the page will create garbage in the text area. Those white zones and garbage disappear when the text is refreshed. Typically, when editing a 1-line area, the latest typed character is hidden by this artefact. And for instance, writing the description of that bug was really painful under those conditions ! (ok I could have used firefox instead... ) PS: please note that the KDE version where this bug appear is not a svn snapshot, but 4.0.4 as your form would not let me chose that option. So please correct the information if you can.
Created attachment 24688 [details] Garbage One example of garbage after scrolling the page.
Created attachment 24689 [details] White rectangle above the right most character.
What is the Qt version you're using?
*** Bug 161896 has been marked as a duplicate of this bug. ***
I am not at home right now, but like the person who reported #161896 I am using official kubuntu packages and have an intel chipset (945GM). It should answer the question about the QT version, I think that 4.4 made it into the hardy backports. The bug is visible whether or not I use desktop effects and does not depend on the QT style.
*** Bug 162257 has been marked as a duplicate of this bug. ***
Broken by this commit: http://lists.kde.org/?l=kde-commits&m=121026258806609&w=2 yey for untested last-minute changes!
Kubuntu backports pushed qt4.4 not long ago; I updated mine 2008-05-18. And from what I can tell I haven't got 4.3 and 4.4 installed; % ldd /usr/lib/kde4/lib/libkhtml.so|grep Qt libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb78ec000) % ls -l /usr/lib/libQtCore.so.4 lrwxrwxrwx 1 root root 18 2008-05-18 14:23 /usr/lib/libQtCore.so.4 -> libQtCore.so.4.4.0 Not that the upgrade fixed anything..
I don't think Dirk's crude backport of the Qt 4.4 regressions turnarounds made it into 4.0.4 so it's rather the lack of this 'fix' that is the problem for people that are running Qt 4.4 with KDE 4.0.X stock (and they should beat their vendors with a big clue stick for doing such a silly thing). Of course, people running Dirk's commit with Qt 4.3 will also experience problems since it's not backward compatible. I'm going to redo it with proper ifdefs.
I have libqt4.4.0 and qt3.3.8 installed. I have the same problem (see http://bugs.kde.org/show_bug.cgi?id=162257)
re: comment #9: this is quite a relief. I've actually done a version with a runtime check: diff --git a/rendering/render_replaced.cpp b/rendering/render_replaced.cpp index 4c1df86..34074f4 100644 --- a/rendering/render_replaced.cpp +++ b/rendering/render_replaced.cpp @@ -584,10 +584,21 @@ static void setInPaintEventFlag(QWidget* w, bool b = true, bool recurse=true) } } +static bool qtVersionDetected = false; +static bool qt43; + +static void detectQtVersion() { + qtVersionDetected = true; + qt43 = QString::fromLatin1(qVersion()).startsWith("4.3"); +} + static void copyWidget(const QRect& r, QPainter *p, QWidget *widget, int tx, int ty, bool buffered = false) { if (r.isNull() || r.isEmpty() ) return; + + if (!qtVersionDetected) + detectQtVersion(); QPoint thePoint(tx, ty); QTransform t = p->worldTransform(); @@ -632,7 +643,7 @@ static void copyWidget(const QRect& r, QPainter *p, QWidget *widget, int tx, int setInPaintEventFlag( widget, false ); - widget->render( d, (buffered ? QPoint(0,0) : thePoint) + r.topLeft(), r); + widget->render( d, (buffered ? QPoint(0,0) : thePoint) + (qt43 ? QPoint(0,0) : r.topLeft()), r); setInPaintEventFlag( widget ); ... but I am quite at a loss to the difference, in particular since the buffer-blitting code seems to use r as a source rect(??)
great, thanks! :-) can you commit it? > ... but I am quite at a loss to the difference, in particular since the > buffer-blitting code seems to use r as a source rect(??) yes, I have no idea why they changed the behaviour. I didn't thought much about it back then, thinking it was some kind of harmonization of behaviour between ports... should have reported it as a bug.
Something is still wrong even w/it --- lineedit backgrounds don't paint reliably. Hmm, this page seems fine though.
with 4.3? I know what it is... you are on NVidia + RenderAccel, right? I have some more fixes I expected to contain to trunk, but if 4.3 is affected too, I'll backport those as well.
Yeah, 4.3, NVidia + RenderAccel. Don't have 4.4 yet --- going to switch to it + trunk shortly, though. The page where I see this is an auto-redirect target from http://webmail.cornell.edu/. I don't recall the problem before, though.
Same here on two machines also running Kubuntu backports. 1 with an Nvidia 8600 GT and another with an onboard Intel (i945?). Problem only showed up on both machines precisely when updating from KDE 4.03 to 4.04.
Problem solved after upgrading from 4.0.4 to 4.00.80 (KDE 4.0.80 >= (KDE 4.1 Beta1) "release 4.1" in openSUSE 10.3
Yo Maksim, Germain, are you happy enough with this to close it?
mmh actually I'd like to let that open some more... there are apparently remaining problems in a few cases (painting of lineedit background when there are several widgets) as Maksim points out in comment #13, for which I have not commited a fix yet because it is quite expensive. This is due to a bug in NVidia drivers with RenderAccel (at least that's the analysis from Trolltech). I 'd like to see more reports if people see occasional smearing in lineedit background, or any other kind of form artifacts in trunk or in branch with Qt 4.4+
*** Bug 163033 has been marked as a duplicate of this bug. ***
*** Bug 163163 has been marked as a duplicate of this bug. ***
HI, I have the same problem at the moment using 4.1.1 and Nvidia driver beta 177.70. SO it is still around :-(
by "same problem", do you mean lineedits (<input type=text>) or textedits (<textarea></textarea>)?
Both of them. EG. when I write into this area just now, I cannot see a thing. Entering the newline the upper line shows, but not entirely. The text is also missing from the commit button below.
Created attachment 27377 [details] patch allright, then I suppose we have no choice but bloat our code and memory usage just for this vendor. Please test attached patch..
OK, just tested and it works partially. I can now see what I am typing in here in the text box, but trying to use google the entry for the search (lineedit?) still show the old symptoms. And the text in the commit button is still missing.
that doesn't make sense to me... could you please verify you have killed all previous konqueror instances after rebuilding and installing - and that "Settings->Configure Konqueror->Performance->Maximum number of instances kept preloaded" is at zero? I'll try and install the beta NVidia driver to see if it botches things... the only symptom I'm seing before the patch is some occasional smearing in lineedits background. Can someone reproduce what dag's seeing?
I only recompiled kdelibs after the patch. It didn't change anythin in the API, did it? But I even booted the system after the recompile. And BTW: The patch didn't apply cleanly, I had to hand apply one part to the 4.1.1 vanilla source.
> It didn't change anythin in the API, the konqueror preload mechanism keeps an hidden instance running, so you could have been running with the old copy of the KHTML library. Nevermind, since you restarted your session. > The patch didn't apply cleanly yeah, I'm not surprised - sorry about that. I've been keeping it around since some time (because it is ugly).
For me, the patch fixes the many repainting problems I see on bugs.k.o: the lineedits in this form look fine, w/o weird bg noise, and the query form repaints properly.
*** Bug 171036 has been marked as a duplicate of this bug. ***
Patch in comment #25 works fine in trunk and Geforce 7600GS+Nvidia 173.17.05. It doesn't apply cleanly, but after a "manual applying", it works.
alright, commited.. thank you for testing. Still not marking as fixed until we see if comment #28 is reproducible. As far as I am concerned, I installed NVidia beta driver, and didn't find any change of behaviour /wrt artifacts... ------------------- SVN commit 861057 by ggarand: .avoid NVidia+Qt4 buffer clearing problems, by making our widgets have a private buffer. .for the same reason, always fully clear our shared opacity buffers - or we might get artifacts on NVidia cards such as on www.codetch.com/screenshots/ M +4 -1 misc/paintbuffer.h M +16 -2 rendering/render_layer.cpp M +2 -0 rendering/render_layer.h M +37 -14 rendering/render_replaced.cpp M +2 -1 rendering/render_replaced.h
Hi again, Can you advice me on how to figure out thi. I would be more than glad to get it sorted out. My graphics card is a Geforce 7600GT. Compiling with gcc 4.2.3 and as earlier said the beta of the Nvidia driver, but upgraded to the beta only because of this problem. In other words the problem existed with the previous driver(s) too. A bit more on the bahviour: - Opening Google I see the button texts might or might not turn up, a reload can show new texts, or then not. - Moving the cursor over the button usually blanks it out, but can also get the text visible again - Writing something in the search field the text might or might not render, and it might or might not turn up completely, or then just the last char (or part of it). At the moment I have the cursor blinking and it blanks out most part of the number 3 that preceeds it. Managed to catch a snapshot of the buttons, attached.
Created attachment 27430 [details] Nvidia render problem
I have to add that there is still some kind of corruption there, when you select the text in an input field. From time to time, some extra pixels appear in the color of text.
Additional info that might be important: - Using Twinview with two monitors beside each other - Running on a Quad core CPU in 64-bit mode Trying to upgrade my compiler to the newest 4.3.2 and recompile, will report the result if any.
Recompiled Qt, kdelibs and kdebase with gcc 4.3.2 => No change
Upgraded to Qt 4.4.2 -> no change
Changing "Compositing type" from OpenGL to XRender makes the line-edit show all characters OK. Still the disappearing text from buttons though. Tried to fiddle with the OpenGL options, but they had no influence. Any xorg.conf options to try?
Fixed the disappearing buttons by a Nvidia setting found on the nvidia forum: nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1 Yeeah, one down. Only line-edit problem left :-)
Installed the latest nvidia beta driver 177.76 and the line editing problems are gone!!! Don't even seem to need the nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1 line, at least not for the rendering. Now I have to figure out why my fonts look so ugly....
Hi again, just tried to install 177.82 (official) because of other X crashes and .... drumroll ... THE BUG is BACK. (Just a report)
With NVidia drivers >180.00, I haven't experienced this bug again. Running on Gentoo. I'd call it fixed.
Hello, I am the reporter of this bug. I must say I haven't had this issue for a long time now. Therefore I change the status to RESOLVED+FIXED. (is it what I am supposed to do?)