Bug 290865

Thanks for the report. I guess you are running Dolphin with the raster engine, where the icons only look sharp only in the sizes 16x16, 22x22, 32x32, 48x48, ...

Could you please check whether running Dolphin with "dolphin -graphicssystem native" resolves your problem? Per default usually the native graphicssystem will be used...

However I'll try to provide also a smooth icon resizing for the raster mode.

With "dolphin -graphicssystem native" icons look good. Compared to that icons in raster mode look terrible.

Please note that most distributions ship with raster by default and Qt 4.8 also uses raster by default. So soon 100% of distributions (with Qt 4.8) will use raster.

Probably I'll need to force Dolphin 2.0 running in the native mode: The raster system is way too slow for the kind of things Dolphin must do :-(

Git commit 8036d2625c14973024894875ba2d2529638620ab by Peter Penz.
Committed on 07/01/2012 at 12:32.
Pushed by ppenz into branch 'KDE/4.8'.

Use the native graphicssystem per default

The scaling of pixmaps is just way too slow with the raster graphicssystem (see KPixmapModifier::scalePixmap()). It is of course still possible to run Dolphin
with the raster graphicssystem, but this has to be done explicitly then.

M  +4    -0    dolphin/src/main.cpp

http://commits.kde.org/kde-baseapps/8036d2625c14973024894875ba2d2529638620ab

Git commit abe876658ce7bdc73f46cfdd0f96bcec71df2df8 by Peter Penz.
Committed on 07/01/2012 at 12:32.
Pushed by ppenz into branch 'master'.

Use the native graphicssystem per default

The scaling of pixmaps is just way too slow with the raster graphicssystem (see KPixmapModifier::scalePixmap()). It is of course still possible to run Dolphin
with the raster graphicssystem, but this has to be done explicitly then.

M  +4    -0    dolphin/src/main.cpp

http://commits.kde.org/kde-baseapps/abe876658ce7bdc73f46cfdd0f96bcec71df2df8

I think with raster dolphin is faster and less cpu hungry. I used raster with kde 4.6 and 4.7 without problem and dolphin was very fast.

I did quick test now, scrolling in big folder with a lot of files. 

What I noticed is huge difference in Xorg cpu usage. With raster it was 7-8 cpu while scrolling, with native it was 30-40% ! Even hovering over different files produces big cpu spikes in dolphin and xorg cpu usage with native graphic system.

So I am sure that for me dolphin is much faster and less cpu hungry with raster. And I saw forum threads where people recommend raster for dolphin.

I don't want to insult you, I am just a user and I am very thankful for your work, but I think forcing native graphic system is bad idea. At least for me, dolphin is much slower (and every other app) with native compared to raster.

The behavior you describe is expected (Xorg takes over some tasks that previously have been done by the Dolphin process), but the important thing for the performance is the number of frames per second. E.g. make a Dolphin window fullsized and do a constant zooming of the icons. On my 2 systems with completely different hardware this task is done a lot times faster with native, as X11 will use hardware acceleration for scaling the images if available. As fallback (like it seems to be in your environment) the CPU is used. But in this case it is "just" as slow as with raster, not slower.

Of course I cannot speak for all combinations out there - if I'm wrong we'll notice it by bug reports ;-)

PS: Sorry, I missed your last sentence that with the native system Dolphin is slower in your environment. So obviously my sentence above "just as slow as with raster, not slower" is not always valid. But I need to take a risk here as in the longterm I think using raster is just crazy... In the worst case this can be reverted in a bugfix release.

> in the longterm I think using raster is just crazy

If a user has a system where raster would be slower than native, then he would really want to change the graphicssystem globally.

Applications must trust Qt (or the user) to select the best system, and the default for Qt 4.8 has changed for a reason. Changing it per-application should only ever been done, if it is not fixable otherwise. For example, krunner must currently use the native system because of X11 accesses to the cursor pixmaps.

I suggest to revert this patch as soon as possible. On many systems the native system is reported to be much slower, even more so on Qt 4.8, where more optimizations have been made to the raster engine. In fact, with the new engine, you do not even have to cache a resized image; scaled rendering is nearly as fast as unscaled rendering.

As a test, on my system I enabled smooth scaling for icons/previews, and it worked as fluid as before. When using native, it was indeed slower.

I should add that KWin developers have worked very hard to *remove* the explicit call to force native engine for KDE 4.8. Thinking about how tied a window manager is to X11, they sure had a reason.

I am with Christoph on this. On my system dolphin with native rendering is huge regression compared to raster.

I think proper fix is to fix icon rendering with raster. It was fine in KDE 4.6 and 4.7 version of dolphin.

Again, I don't want to be rude and insult you Peter, I just want the best for KDE. That's why I installed RC2 on my main system. To give it the best posible testing and report bugs.

+1 vote for reverting this patch.

Git commit 88846fec48cca0b33c19627502d099e7215ba496 by Peter Penz.
Committed on 07/01/2012 at 18:18.
Pushed by ppenz into branch 'master'.

Revert patch using the native graphicssystem as default

I'm trusting Christoph Feck's advice here. Additionally the smooth scaling
has been activated to fix bug 290865.
FIXED-IN: 4.8.0

M  +2    -2    dolphin/src/kitemviews/kpixmapmodifier.cpp
M  +0    -4    dolphin/src/main.cpp

http://commits.kde.org/kde-baseapps/88846fec48cca0b33c19627502d099e7215ba496

Git commit ee0c8596905b9e0b2ab00d3ae9e057731357acb9 by Peter Penz.
Committed on 07/01/2012 at 18:18.
Pushed by ppenz into branch 'KDE/4.8'.

Revert patch using the native graphicssystem as default

I'm trusting Christoph Feck's advice here. Additionally the smooth scaling
has been activated to fix bug 290865.
FIXED-IN: 4.8.0

M  +2    -2    dolphin/src/kitemviews/kpixmapmodifier.cpp
M  +0    -4    dolphin/src/main.cpp

http://commits.kde.org/kde-baseapps/ee0c8596905b9e0b2ab00d3ae9e057731357acb9

@Christoph: I'm trusting you here and have reverted your patch. However I'm quite confused: AFAIK the raster engine does not use any GPU, so I'm wondering how a scaling of pixmaps can be done at all without noticeable performance drawback. So if the raster engine in 4.8 takes advantage of a GPU then of course I'm taking back my "is just crazy" statement from above ;-)

@Nikola:
> Again, I don't want to be rude and insult you
> Peter, I just want the best for KDE.

You never had been rude at all ;-) I'm glad that you took the time to report this issue and that you responded so fast. As you see the discussion resulted in resolving your bug: I would not have activated the smooth scaling before Christoph said that he has activated it on his system and that it performs well.