Re: [gentoo-user] slow redrawing in KDE

2005-07-19 Thread Richard Fish

Jorge Almeida wrote:


On Mon, 18 Jul 2005, Richard Fish wrote:


If so, possibly an error with themes or alpha blending...


But why now?



Well, one of the things that has been happening in the xorg/qt/kde world 
is a move towards more eye-candy with transparency, drop shadows, and so 
on.  My guess is that this version of KDE is trying to use a new method 
of drawing things, that turns out to be slower than the old (or maybe 
more accurately, plain) method for your hardware.


You might take a walk through the KDE option menus and disable anything 
that says drop shadows, transparency, or most other eye-candy.




Could you post the output xdpyinfo...I have a feeling the answer is 
going to be in there.



$ xdpyinfo


snip


number of extensions:33
BIG-REQUESTS
Composite



Could you try disabling this.  From googling, it seems that something 
like the following in xorg.conf should do it:


Section Extensions
   Option Composite Disable
EndSection

Everything else looks sane.

-Richard

--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-19 Thread Jorge Almeida

On Tue, 19 Jul 2005, Richard Fish wrote:



You might take a walk through the KDE option menus and disable anything that 
says drop shadows, transparency, or most other eye-candy.



I had done that already. But I like eye-candy, or I might as well use a
minimalistic wm...
(I didn't get shadows or transparency anyway, whwn it was enabled.)



number of extensions:33
BIG-REQUESTS
Composite



Could you try disabling this.  From googling, it seems that something like 
the following in xorg.conf should do it:


Section Extensions
  Option Composite Disable
EndSection

I did it (actually, I commented out the whole section). I guess things are 
better. I still can see widgets in mozilla
windows showing in a cascading way, but time lag is small.

BTW: that Section was the last one in xorg.conf, and vim suggested there
was something wrong with it (different colors than other sections), but
it's beyond me to guess what.


Everything else looks sane.

-Richard


Thanks.

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Sun, 17 Jul 2005, Zac Medico wrote:


Jorge Almeida wrote:

I just emerged KDE, changing from the monolytic packages to the split
ones.
Now windows redrawing is painfully (and cas-ca-ding) slow.
The problem seems to be the same as in
http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html
(but no answer there...)
Any idea?




First step to isolate this problem, I'd install a minimalist wm such as 
x11-wm/openbox and see which apps I can reproduce the problem with there, if 
any.


Zac


Not that easy. The problem is more visible when the desktop is filled
with a Mozilla window and I change to this desktop. I would need a wm
with virtual desktops and it had to be possible to change desktops via
keyboard.

I'm getting tired of KDE: each upgrade brings new problems. I would give
it up if I could find a wm supporting multiple desktops (with the
possibility of different backgrounds) and control via keyboard. I can't
get KDE's goodies, like shadows and transparency, to work, anyway...

Thanks for the reply.

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Zac Medico

Jorge Almeida wrote:

On Sun, 17 Jul 2005, Zac Medico wrote:


Jorge Almeida wrote:


I just emerged KDE, changing from the monolytic packages to the split
ones.
Now windows redrawing is painfully (and cas-ca-ding) slow.
The problem seems to be the same as in
http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html 


(but no answer there...)
Any idea?




First step to isolate this problem, I'd install a minimalist wm such 
as x11-wm/openbox and see which apps I can reproduce the problem with 
there, if any.


Zac


Not that easy. The problem is more visible when the desktop is filled
with a Mozilla window and I change to this desktop. I would need a wm
with virtual desktops and it had to be possible to change desktops via
keyboard.

I'm getting tired of KDE: each upgrade brings new problems. I would give
it up if I could find a wm supporting multiple desktops (with the
possibility of different backgrounds) and control via keyboard. I can't
get KDE's goodies, like shadows and transparency, to work, anyway...

Thanks for the reply.

Jorge


Openbox supports multiple desktops.  You can replace the default kde window 
manager (kwin) with openbox: 
http://icculus.org/openbox/docs.php?page=build.html#install-kde

Zac
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Zac Medico wrote:


Openbox supports multiple desktops.  You can replace the default kde window 
manager (kwin) with openbox: 
http://icculus.org/openbox/docs.php?page=build.html#install-kde


Zac


Browsing the documentation, it seems it doesn't support setting the
background. I'll have a look at third party applications...
I really need commuting desktops with keys, and different backgrounds
allow me to know where I am.

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Zac Medico

Jorge Almeida wrote:

On Mon, 18 Jul 2005, Zac Medico wrote:



Openbox supports multiple desktops.  You can replace the default kde 
window manager (kwin) with openbox: 
http://icculus.org/openbox/docs.php?page=build.html#install-kde


Zac


Browsing the documentation, it seems it doesn't support setting the
background. I'll have a look at third party applications...
I really need commuting desktops with keys, and different backgrounds
allow me to know where I am.

Jorge


I wasn't suggesting Openbox as a permanent solution.  It's just a troubleshooting tool to 
help you isolate the problem.  I use KDE 3.4.1 (split ebuilds) and haven't noticed any 
redraw problems like you're experiencing.  Does the problem only affect kde 
apps?  How about a qt app with no kde support? Gtk apps are fine?

Zac
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Volker Armin Hemmann
On Monday 18 July 2005 10:17, Jorge Almeida wrote:
 On Sun, 17 Jul 2005, Zac Medico wrote:
  Jorge Almeida wrote:
  I just emerged KDE, changing from the monolytic packages to the split
  ones.
  Now windows redrawing is painfully (and cas-ca-ding) slow.
  The problem seems to be the same as in
  http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.ht
 ml (but no answer there...)
  Any idea?
 
  First step to isolate this problem, I'd install a minimalist wm such as
  x11-wm/openbox and see which apps I can reproduce the problem with there,
  if any.
 
  Zac

 Not that easy. The problem is more visible when the desktop is filled
 with a Mozilla window and I change to this desktop. I would need a wm
 with virtual desktops and it had to be possible to change desktops via
 keyboard.


so, not kde, but mozilla is slow?
Slow redreaw of gtk is known.

Do you have enough ram?
If you need swap, kde is dead slow.
Is RenderAccel on?
Is KDE prelinked?
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Zac Medico

Volker Armin Hemmann wrote:

Do you have enough ram?
If you need swap, kde is dead slow.


This one should be *really* obvious.  If the hard drive is thrashing, you're 
out of ram :-).

Zac
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Volker Armin Hemmann wrote:




so, not kde, but mozilla is slow?
Slow redreaw of gtk is known.

Do you have enough ram?
If you need swap, kde is dead slow.
Is RenderAccel on?
Is KDE prelinked?


It's not a RAM problem (512M, and top shows it's not leaking somewhere).
KDE is not prelinked. I don't know about RenderAccel (how can I tell?).
Anyway, I didn't change anything except KDE. Slow rendering shows mainly
with Mozilla and Thunderbird. With gvim too, I suppose (hard to tell).
But Mozilla was fine before.

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Volker Armin Hemmann
On Monday 18 July 2005 12:15, Jorge Almeida wrote:
 On Mon, 18 Jul 2005, Volker Armin Hemmann wrote:
  so, not kde, but mozilla is slow?
  Slow redreaw of gtk is known.
 
  Do you have enough ram?
  If you need swap, kde is dead slow.
  Is RenderAccel on?
  Is KDE prelinked?

 It's not a RAM problem (512M, and top shows it's not leaking somewhere).
 KDE is not prelinked. I don't know about RenderAccel (how can I tell?).
 Anyway, I didn't change anything except KDE. Slow rendering shows mainly
 with Mozilla and Thunderbird. With gvim too, I suppose (hard to tell).
 But Mozilla was fine before.


well 512 is most of the time enough, but not always ;)

hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow. 

Search google for gtk and slow and you'll find a lot ;)

RenderAccel is set in your xorg.conf - if you have nvidia.
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Volker Armin Hemmann wrote:





well 512 is most of the time enough, but not always ;)

I know, but I checked top.


hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow.

But it wasn't noticeable before... It looks as if the several widgets
were being shown _before_ the main window...


Search google for gtk and slow and you'll find a lot ;)

RenderAccel is set in your xorg.conf - if you have nvidia.

Ati Radeon 7500.




--
Jorge Almeida
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Rumen Yotov
Jorge Almeida wrote:

 On Mon, 18 Jul 2005, Volker Armin Hemmann wrote:



 well 512 is most of the time enough, but not always ;)

 I know, but I checked top.


 hm, if only gtk apps are slow, it is normal - gtk IS slow. Very slow.

 But it wasn't noticeable before... It looks as if the several widgets
 were being shown _before_ the main window...


 Search google for gtk and slow and you'll find a lot ;)

 RenderAccel is set in your xorg.conf - if you have nvidia.

 Ati Radeon 7500.



Hi,
Think i can't of great help here, but at least twice when i had slow
graphical performance solved it by re-emerging some packages and
xorg-x11 once (i assume you have run 'revdep-rebuild' ;)
As it seems your main DM is KDE it's likely that there may be issues
with GTK-apps, as their libs/deps also get loaded when mozilla/etc is run.
Here's some info:
1.mozilla dependencies:
...www-client/mozilla-1.7.8:
crypt? !moznomail? =app-crypt/gnupg-1.2.1 app-crypt/gnupg-1.4.1
postgres?   =dev-db/postgresql-7.2.0 dev-db/postgresql-8.0.1-r4
=dev-libs/glib-2.2.0dev-libs/glib-2.6.4
=dev-libs/libIDL-0.8.0  dev-libs/libIDL-0.8.5
=media-libs/fontconfig-2.1 media-libs/fontconfig-2.2.3
=media-libs/jpeg-6b media-libs/jpeg-6b-r4
=media-libs/libmng-1.0.0 media-libs/libmng-1.0.8-r1
=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8
=sys-apps/portage-2.0.36 sys-apps/portage-2.0.51.22-r1
=sys-libs/zlib-1.1.4sys-libs/zlib-1.2.2-r1
=www-client/mozilla-launcher-1.22
www-client/mozilla-launcher-1.32
=www-client/mozilla-launcher-1.28
www-client/mozilla-launcher-1.32
=x11-libs/gtk+-2.2.0x11-libs/gtk+-2.6.7
=x11-libs/pango-1.2.1   x11-libs/pango-1.8.1
app-arch/unzip   app-arch/unzip-5.50-r2
app-arch/zip app-arch/zip-2.3-r4
dev-lang/perldev-lang/perl-5.8.6-r5
dev-libs/expat   dev-libs/expat-1.95.8
dev-util/pkgconfig   dev-util/pkgconfig-0.17.2-r1
!bootstrap? sys-devel/patch  sys-devel/patch-2.5.9
virtual/x11  x11-base/xorg-x11-6.8.2-r2
!moznoxft?  virtual/xft  x11-base/xorg-x11-6.8.2-r2
~sys-devel/autoconf-2.13 sys-devel/autoconf-2.13
...
2.GTK+ dependencies:
...x11-libs/gtk+-2.6.7:
=dev-libs/atk-1.0.1 dev-libs/atk-1.9.1
=dev-libs/glib-2.6  dev-libs/glib-2.6.4
=dev-util/pkgconfig-0.12.0 dev-util/pkgconfig-0.17.2-r1
jpeg?   =media-libs/jpeg-6b-r2  media-libs/jpeg-6b-r4
=media-libs/libpng-1.2.1 media-libs/libpng-1.2.8
=sys-devel/automake-1.7.9 sys-devel/automake-1.9.5
=x11-libs/pango-1.8 x11-libs/pango-1.8.1
sys-devel/autoconf   sys-devel/autoconf-2.59-r6
!bootstrap? sys-devel/patch  sys-devel/patch-2.5.9
virtual/x11  x11-base/xorg-x11-6.8.2-r2
x11-misc/shared-mime-info x11-misc/shared-mime-info-0.16

...
IMHO you could first try emerging: glibgtk+ and probably in second
place: xorg-x11.
There are also many image-manupulation libraries: jpeg,png,mng
HTH. Rumen


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Richard Fish

Jorge Almeida wrote:


But it wasn't noticeable before... It looks as if the several widgets
were being shown _before_ the main window...



So, if I understand you correctly, some mozilla controls get drawn long 
before the titlebar?  Is that right?


If so, possibly an error with themes or alpha blending...

Could you post the output xdpyinfo...I have a feeling the answer is 
going to be in there.


-Richard

--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Benno Schulenberg
Jorge Almeida wrote:
 I just emerged KDE, changing from the monolytic packages to the
 split ones.
 Now windows redrawing is painfully (and cas-ca-ding) slow.

Have you tried renaming your .kde3.4/ dir temporarily (while logged 
out of KDE)?  And removed all kde and mcop junk from /tmp?

Have you unmerged the old kde ebuilds?  And done --depclean?  And 
revdep-rebuild?

Benno
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Richard Fish wrote:


Jorge Almeida wrote:


But it wasn't noticeable before... It looks as if the several widgets
were being shown _before_ the main window...



So, if I understand you correctly, some mozilla controls get drawn long 
before the titlebar?  Is that right?

Yep.


If so, possibly an error with themes or alpha blending...

But why now?


Could you post the output xdpyinfo...I have a feeling the answer is going 
to be in there.


$ xdpyinfo
name of display::0.0
version number:11.0
vendor string:Gentoo Linux (The X.Org Foundation 6.8.2, revision r1-0.1.2)
vendor release number:60802000
X.Org version: 6.8.2
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:32, LSBFirst, 32
image byte order:LSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus:  window 0x2a00049, revert to PointerRoot
number of extensions:33
BIG-REQUESTS
Composite
DAMAGE
DEC-XTRAP
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RANDR
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFIXES
XFree86-Bigfont
XFree86-DGA
XFree86-DRI
XFree86-Misc
XFree86-VidModeExtension
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number:0
number of screens:1

screen #0:
  print screen:no
  dimensions:1280x1024 pixels (325x260 millimeters)
  resolution:100x100 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0x41
  depth of root window:24 planes
  number of colormaps:minimum 1, maximum 1
  default colormap:0x20
  default number of colormap cells:256
  preallocated pixels:black 0, white 16777215
  options:backing-store NO, save-unders NO
  largest cursor:64x64
  current input event mask:0xfa4035
KeyPressMask ButtonPressMask  EnterWindowMask
LeaveWindowMask  KeymapStateMask  StructureNotifyMask
SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask
PropertyChangeMask   ColormapChangeMask
  number of visuals:9
  default visual id:  0x23
  visual:
visual id:0x23
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x24
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x25
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x26
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x27
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x28
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x29
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x2a
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x3f
class:TrueColor
depth:32 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits

--
Jorge Almeida
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Rumen Yotov wrote:

Hi,
Think i can't of great help here, but at least twice when i had slow
graphical performance solved it by re-emerging some packages and
xorg-x11 once (i assume you have run 'revdep-rebuild' ;)
As it seems your main DM is KDE it's likely that there may be issues
with GTK-apps, as their libs/deps also get loaded when mozilla/etc is run.
Here's some info:
1.mozilla dependencies:
...www-client/mozilla-1.7.8:
   crypt? !moznomail? =app-crypt/gnupg-1.2.1 app-crypt/gnupg-1.4.1
   postgres?   =dev-db/postgresql-7.2.0 dev-db/postgresql-8.0.1-r4
   =dev-libs/glib-2.2.0dev-libs/glib-2.6.4
   =dev-libs/libIDL-0.8.0  dev-libs/libIDL-0.8.5
   =media-libs/fontconfig-2.1 media-libs/fontconfig-2.2.3
   =media-libs/jpeg-6b media-libs/jpeg-6b-r4
   =media-libs/libmng-1.0.0 media-libs/libmng-1.0.8-r1
   =media-libs/libpng-1.2.1 media-libs/libpng-1.2.8
   =sys-apps/portage-2.0.36 sys-apps/portage-2.0.51.22-r1
   =sys-libs/zlib-1.1.4sys-libs/zlib-1.2.2-r1
   =www-client/mozilla-launcher-1.22
www-client/mozilla-launcher-1.32
   =www-client/mozilla-launcher-1.28
www-client/mozilla-launcher-1.32
   =x11-libs/gtk+-2.2.0x11-libs/gtk+-2.6.7
   =x11-libs/pango-1.2.1   x11-libs/pango-1.8.1
   app-arch/unzip   app-arch/unzip-5.50-r2
   app-arch/zip app-arch/zip-2.3-r4
   dev-lang/perldev-lang/perl-5.8.6-r5
   dev-libs/expat   dev-libs/expat-1.95.8
   dev-util/pkgconfig   dev-util/pkgconfig-0.17.2-r1
   !bootstrap? sys-devel/patch  sys-devel/patch-2.5.9
   virtual/x11  x11-base/xorg-x11-6.8.2-r2
   !moznoxft?  virtual/xft  x11-base/xorg-x11-6.8.2-r2
   ~sys-devel/autoconf-2.13 sys-devel/autoconf-2.13
...
2.GTK+ dependencies:
...x11-libs/gtk+-2.6.7:
   =dev-libs/atk-1.0.1 dev-libs/atk-1.9.1
   =dev-libs/glib-2.6  dev-libs/glib-2.6.4
   =dev-util/pkgconfig-0.12.0 dev-util/pkgconfig-0.17.2-r1
   jpeg?   =media-libs/jpeg-6b-r2  media-libs/jpeg-6b-r4
   =media-libs/libpng-1.2.1 media-libs/libpng-1.2.8
   =sys-devel/automake-1.7.9 sys-devel/automake-1.9.5
   =x11-libs/pango-1.8 x11-libs/pango-1.8.1
   sys-devel/autoconf   sys-devel/autoconf-2.59-r6
   !bootstrap? sys-devel/patch  sys-devel/patch-2.5.9
   virtual/x11  x11-base/xorg-x11-6.8.2-r2
   x11-misc/shared-mime-info x11-misc/shared-mime-info-0.16

...
IMHO you could first try emerging: glibgtk+ and probably in second
place: xorg-x11.
There are also many image-manupulation libraries: jpeg,png,mng
HTH. Rumen


Sigh I guess it's going to be a long week...
Thanks :)

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida


On Mon, 18 Jul 2005, Benno Schulenberg wrote:


Have you tried renaming your .kde3.4/ dir temporarily (while logged
out of KDE)?  And removed all kde and mcop junk from /tmp?

Have you unmerged the old kde ebuilds?  And done --depclean?  And
revdep-rebuild?


No. I think a deep cleaning is in order.
Thank you.

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Zac Medico

Jorge Almeida wrote:


...
IMHO you could first try emerging: glibgtk+ and probably in second
place: xorg-x11.
There are also many image-manupulation libraries: jpeg,png,mng
HTH. Rumen


Sigh I guess it's going to be a long week...
Thanks :)

Jorge


Something that's still unclear to me: is the problem with kde, mozilla, or 
both?  If you experience the same problem with mozilla under openbox then your 
troubles have nothing to do with kde. OTOH, if you there's no problems under 
openbox then the problem is in X/glib/gtk/mozilla.

You can greatly reduce the troubleshooting time if you go about it in a 
systematic way (process of elimination/scientific method) to isolate the 
problem.

Zac
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-18 Thread Jorge Almeida

On Mon, 18 Jul 2005, Zac Medico wrote:
Something that's still unclear to me: is the problem with kde, mozilla, or 
both?  If you experience the same problem with mozilla under openbox then 
your troubles have nothing to do with kde. OTOH, if you there's no problems 
under openbox then the problem is in X/glib/gtk/mozilla.

No problem under openbox.
The problem manifests with mozilla, but only after upgrading KDE.
All is probablly my fault, for not keeping my system clean. I'm in the
cleaning process now...

Jorge
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] slow redrawing in KDE

2005-07-17 Thread Zac Medico

Jorge Almeida wrote:

I just emerged KDE, changing from the monolytic packages to the split
ones.
Now windows redrawing is painfully (and cas-ca-ding) slow.
The problem seems to be the same as in
http://forums.gentoo.org/viewtopic-t-344889-highlight-kde+slow+redraw.html
(but no answer there...)
Any idea?




First step to isolate this problem, I'd install a minimalist wm such as 
x11-wm/openbox and see which apps I can reproduce the problem with there, if 
any.

Zac
--
gentoo-user@gentoo.org mailing list