[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Speed on moving split-panes in KDE apps.
From:       Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2009-12-06 16:52:33
Message-ID: 200912061752.34487.thomas.luebking () web ! de
[Download RAW message or body]

The difference between kate and dolphin is that kate ("still") uses a 
qsplitter rather than a QDockWidget.

In addition QSplitter can ::setOpaqueResize(false); what (apparently) juk 
does.

There /was/ a similar flag for Q3DockWindow, but that's from Qt3Support (i.e. 
NO! ;-)

Usually the culprit is the relayout/repaint in the 
QMainWindow::centralWidget(), i.e. usually webkit or iconviews.
(in dolphin, try adding a dock on the left and the right, then grow one of 
them until the centralWidget() can't shrink anymore, then resize docks on the 
splitter so that the iconview /would/ but cannot shrink -> relayouting is 
pretty fast.

So if you want to optimize, optimize on your centralWidget behaviour on 
resizes/repaints (caching, catch resizes and avoid expensive parts if you can 
estimate that a relayout isn't required....

Am Sunday 06 December 2009 schrieb Tomaz Canabrava:
> There's something that's currently bothering me a bit on Qt & KDE apps.
>  Since sometimes kde-trunk breaks, I have also a Gnome installation by side
>  just to be sure I wont be able to use a graphical interface on those
>  situations. but when I open a KDE app it feels sluggish compared to GTK
>  ones while moving split-panes and redimensioning the screen, this happens
>  on my app too, rocs, I wonder what can I do to improve this situation. the
>  overall is that kde is faster than gnome, but feels slower because of
>  those drawing things, resizing windows and split panes is a pain ( well,
>  not a pain, but it doesn't feels instant like gtk apps do). at first I
>  tougth it was because I was using a Qt compiled with debug info, and a kde
>  compiled with debugfull. but this week I did a complete new compilation,
>  and both kde and qt are in release mode, and that still got into it. so I
>  got worried.
> 
> another things, conserning visual consistency.:
> 
> Juk split pane is completely different from the other split panes in KDE,
>  it doesn't tries to redraw the screen while moving, instead it shows a
>  translucent squade of where the split pane will be, is this correct? I
>  mean, we don't need to integrate the visual apparence of all apps?
> 
> Kate's Split pane on open document is almost good as gtk apps, but not so
> quite,
> 
> Dolphin's the worse on, moving 'Locals', when moving 'Information', it's
>  ok, and 'Folders' is not good either.
> I want some direction to try to improve those situations.
> 
> Best regards,
> 
> Tomaz
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<
> 

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]