Version: (using KDE KDE 3.1.1a) Installed from: Gentoo Packages OS: Linux When switching between tabs in Konqueror, there is a noticeable flicker, since for a brief moment, the background color of the window is drawn before the vontents of the next tab are drawn. The result is a flickering. This seems to be a general phenomenon when switching between menus and such in KDE; Gnome, OS X and Windows XP don't do this, and KDE would be much improved in terms of appearance if it didn't do this either. Praveen Srinivasan
*** Bug 59111 has been marked as a duplicate of this bug. ***
Hello, the flicker even happens when you stay on the same tab and same page, and simply press "Reload". I've tried it out with a simple local htmlfile. regards, Yves
is it possible to change this bugs status from "wishlist" to "normal"?
This report is a dupe of Bug 39234, both cases are about dynamically updated toolbar icons flickering as soon as they are dynamically updated.
It's not a dupe (tab bar!=tool bar, bug 39234 is about switching between different kparts). About the flickering in the tab bar itself (bug 59111) I have sent a report/patch to Trolltech so there will likely an official patch soon. What stays open is the flickering in the content area (part redrawing when shown()?).
*** Bug 60172 has been marked as a duplicate of this bug. ***
See qt-copy/patches/0013-qtabwidget-less_flicker.patch for the proposed patch mentioned in comment 5.
With 0013-qtabwidget-less_flicker.patch flickering reduced very much but it still flickers when you close the last tab ( leaving no tabs ) .
Possible solution to flicks on closing tabs could be to have a option for always show tabs
At least in my KDE 3.2 CVS version is not the tabbar but the dinamic part of the toolbar what flickers when you change between tabs, create or close one. I guess this is inevitable when the views of the tabs are diferent (e.g. webbrowsing and file manager) because, after all, the diferent dinamic toolbars need to be updated and redrawn, but it could be avoided when you change between two tabs with the same view (like webbrowsing) just noticing that the tab the user wants to change to don't need a diferent dinamic toolbar and thus not redrawing it (and it could also be a little optimization). Just my 2 euro cents. (Should this bug report be closed and a new one filed against the dinamic toolbar opened?)
This isn't just a problem with tabs as was noted by Yves Glodt; it's a problem with redrawing the scrollviews for as far as I know. My report, dating end-2002 describes this behaviour as well (bug 52026) : There is some redrawing behaviour with KHTML that's rather disturbing. The following is what is taking place : - Visit a website with a non-default background color - Scroll a little (doesn't matter how much) down the page - Now hit F5 (reload), go back in history or click on a link You can see the view is completely erased with the default background color first, after which the page is rendered on it (with a different background color). In effect, this results in a completely white view for a short moment during browsing - very stressful for the eyes (especially when this background turns to black after this white flash). The strange thing is (that is, to me) that this behaviour is not observed when you don't scroll, or scroll back to the top of the page (so the page is completely at the beginning). As this is pretty bad on the eyes and because IE and Mozilla both handle this 'properly' I was wondering if anyone had an idea about how much trouble it would be to fix this. I've looked through the source myself but, as I expected on beforehand, I couldn't locate the place where this gets done. ---- Mark my bug as a dupe of this one (and get 40 votes ? :) ?
In KDE 3.1.4 flicking when you change to another tab is not so annoying that when you create the first tab (the tabbar appears) or when you close the last tab (the tab bar disappears) in both cases the effect is very disagreeable. Others navigators have solved it always showing the tab-bar. Current flicking by the change of tabs is acceptable for me, at least ;)
There is a LOT less flicker in current CVS head, but still a little bit.
I don't see any flicker, using kde beta 2. Should this bug not be CLOSED?
IMHO no! Right now I use the slax bootable cd which has beta2, and I still observe the following with the toolbar: When you switch between two tabs, the 5 last icons on the toolbar ("Print frame", "Find", "Increase font sizes", "Decrease font sizes", "Security", "Download manager") get completely removed, and then redrawn immediately. I would still describe that behaviour as "flicker"... As mentioned before, a solution would be not repainting anything unless the protocol between the tabs has actually changed (e.g. from http:// to file:/, and thus justifying new/other icons on the toolbar) ... ok, did some more testing, it's really odd... Look this tab setup: Tab1: http://foo.bar Tab2: http://foo.bar Tab3: file:/ Tab4: http://foo.bar Switching between Tab 1 and 4 causes nearly no flickering toolbar icons -> ok Switching between Tab 2 and 4 is the same as above -> ok Switching between Tab 1 and 2 causes a lot of flicker -> bad Switching between Tab 2 and 3 or 3 and 4 causes nearly no flicker again -> ok HTH
Using KDE 3.2 RC1 from Mandrake RPMs. The issues described above are mostly fixed. There's no flicker when creating tabs, removing tabs, or when a tab gets renamed. Tabbar is redrawn only once which is ok. The big problem now is creating new tabs when tabbar is already full. Try it and you'll see the horror. It seems that the original intention was that there is an animation of other tabs sliding to make space for the new tab, however this flickers horribly and is very painful to my eyes. Is there a way to disable this animation? Why can't tabbar behave just like taskbar? I usually configure KDE to run with max CPU so I guess this animation should be just as fast as all the others.
!? The problem was there in Mandrake 10 beta1, and now dissapeared with update to beta2. It could have something to do with optimizations used when compiling. Ah well... you can close the bug now AFAIAC (...am concerned)
Does anyone have this problem with the current CVS?
is ok for me in 3.2.1
well, but there is however room for improvement... These 2 cases are still flicker-intensive: - Opening a new Tab by pressing CTRL-T (seems to flicker more than using Location->New Tab)... - In a newly opened tab (which has the title "about:blank"), enter an url and press ENTER, and you'll see massive flicker when the tab-width changes due to the tab-title changing from "about:blank" to the title of the website.
I noticed another kind of flicker. It happens also when switching between 2 tabs, and is best visible when you open the same website twice, in separate tabs. Now when you switch between those tabs, you can observe a flicker of the outer frame and the statusbar of the rendered page. The tabs themselves don't flicker in this case. This is on 3.2.2.
*** Bug 80979 has been marked as a duplicate of this bug. ***
CVS commit by zrusin: Fixing flicker on initial showing of the tabbar. CCMAIL: 58040@bugs.kde.org M +0 -2 konq_mainwindow.cc 1.1334 M +43 -7 konq_tabs.cc 1.51 M +7 -1 konq_tabs.h 1.19 M +9 -66 konq_viewmgr.cc 1.266 M +0 -4 konq_viewmgr.h 1.79
I have an observation of this behaviour in KDE 3.3. Although flicker has been reduced a lot, there is still some room for improvements... Everytime you open a new tab, you have the last 6 toolbar icons (Printer, Find, etc) flickering shortly. The same happens when you close a tab.
For me, the 5 icons that flicker are: Find, Increase Text Size, Decrease Text Size, Security, and KGet. I just realized - these are mostly the ones on the KHTMLPart toolbar, so they must be flickering as konqueror "detects" which KPart to use on the new tab.
Apparently the remaining beef is against the part-specific toolbar icons (-> retitling). A very difficult problem to solve IMHO, given the KParts design (those icons are provided by the part, and when switching you go to another part...). AFAIK we already delay and reduce the repainting of the toolbar (Waldo's work from some time ago), so I'm not sure if much more can be done at the toolbar level.
Today I started using the keramik style, and magically... flicker is greatly reduced, as far that I could consider it WFM. So maybe all the trouble I described was related to the plastik widgetstyle...
Maybe have the parts-embedding apps implement a small interface to be used by kparts (automatically) in order to find out whether their toolbars are already shown? I don't know whether the current architecture still allows this and how easy it is to do, just an idea.
Just to note that the flicker still happens in KDE 3.4.0-rc1. Enrico Ros was a hero some time ago when he discovered and sent patches to correct several flickerings on Konqueror, maybe someone can follow his footsteps and correct this really old bug.
Yes, it would be really nice that people checked this. But oh well, kde rocks anyway ;)
I still notice flicker (or more a onetime flashing) in the content area, when I switch from one tab to another. This flash even happens when both tabs show exactly the same content. Should I open a new BR for this?
Description of situation in KDE3.4.2: - Open 2 tabs with the same content (webpage or local directory) - switch from 1 tab to the other by e.g. mousewheeling over the tabbar Watch everything beyond the tabbar flicker (scrollbars, statusbar, frame)
s/beyond/below in my last comment
I don't see this is a large problem but did want to clarify what is happening. When you switch between two tabs displaying the same type of content this appears to be a flicker but what is happening is an unneeded redraw. What is most noticeable is the content specific parts of the toolbars. The toolbars are first redrawn without these icons and then redrawn again with them. I am using Qt-3.3.6 on a 400 MHz system and this is the only thing I can see. Perhaps the other issues have been fixed. The same thing happens when switching between between tabs with different types of content. First the toolbar is redrawn without the content specific icons and then redrawn again with the different content specific icons for the new type of content. The cure for the problem is to eliminate the unneeded redraw.
Another unneeded redraw is disbribed here: http://bugs.kde.org/show_bug.cgi?id=58040 maybe they are linked
here in fact: http://bugs.kde.org/show_bug.cgi?id=124319 :-|
One sub-case of this is that a new tab opens with no text, but then resizes when the text "about:blank" is inserted. If it could open with "about:blank" instead of redrawing, that would be a good start.
nothing flickers , i am using kubuntu 6.10,kde 3.5.5,Konqueror 3.5.5
This is fixed in KDE4 with r716094
This has somehow reappeared in KDE 4.1. Here, the complete tab-, url- and icon-toolbar flickers when I create a new tab, or when I switch between tabs.
I still see this bug in the kde 4.4 rc1 packages in kubuntu lucid/amd64 But it happens only after the flash plugin was loaded in one of the tabs at least once. Even then you can close the flash-using tab, and reopen new tabs, the flicker will still be there. Close Konq again, browse flash-free sites, and there is no more flicker.
I don't suppose this is Kubuntu specific?
I have no other distro running so I can not test. Apart of that, this BR is probably related: https://bugs.kde.org/show_bug.cgi?id=190728
Cannot reproduce using KDE SC 4.4.5
*** Bug 190728 has been marked as a duplicate of this bug. ***
Still there with 4.4.95.
(And I'm using opensuse 11.3. But I think it was there with Fedora 13 as well.)
Still there in KDE 4.5. But only happened after I messed around with the toolbar. By default the option “only display icon” is set, after switching to “text below icons” the problems began.
I'm using KDE 4.6, with toolbars with icons only and this is still present. Granted I'm testing this with an Atom N270 which has about the same level of performance as what was available when this bug was originally created... 7 years ago!
*** Bug 267555 has been marked as a duplicate of this bug. ***