What widget style are you using?

Hi,

I use the ugly one :) No jokes, QTCurve doesn't work as it should on R14, so I have to use the default one (Plastik).

I get the same behaviour with any widget style.

-Alexandre

Created attachment 1419 [details]
Kicker debug info while using KFaenza

Hi,

I saw today that Kicker has no slowdowns when I use the KFaenza icon theme, as I use on my remaster. By switching back and forth between KFaenza and Crystal SVG, I can see clearly the difference:
Crystal SVG: It takes 5-6 seconds before Kicker appears and navigating between the submenus is slow.
KFaenza:Kicker appears instantly and submenus too appears instantly.

Hope it can help.

-Alexandre

Yes, this helps a lot!  That isolates the slowdown as something in the SVG parsing code.

Is there a program I could run gdb against to help you on this?

Except for QTCurve theme that is not working as it should, it is problably the last bug that annoys me on R14 for the moment. Not using the half-working HAL will be a great step forward for TDE and it will be a great release.

Thanks!
-Alexandre

The only thing that might help is to attach gdb to the Kicker process (gdb --pid `pidof kicker`), resume execution (r), then try to load the TDE menu.  Wait 5 seconds or so (the menu should not appear in this time, as attaching gdb really slows Kicker down!) and ctrl+c the gdb process once.  Generate a backtrace and post it here.

Thanks!

Created attachment 1421 [details]
Kicker debug info with resume

Hi,

I guess that it didn't work properly, but when I did the resume, the whole taskbar disappear. You will see in the debug info that other TDE parts stopped to work at that moment.

-Alexandre

(In reply to comment #8)
> Created attachment 1421 [details]
> Kicker debug info with resume
> 
> Hi,
> 
> I guess that it didn't work properly, but when I did the resume, the whole
> taskbar disappear. You will see in the debug info that other TDE parts stopped
> to work at that moment.
> 
> -Alexandre

Rather than typing "r", type "c" in gdb.  What you did was to restart kicker in the GDB session, which is why TDE broke. :-)

Once the menu is loading/stalled, enter "Ctrl+C" into the gdb process, then excecute "bt" at the (gdb) prompt.  Attach the output of that command to this report.

Thanks!

Tim

Created attachment 1453 [details]
TDE with Crystal SVG

Ok, I'm (mostly) sure I found the root of the problem: the LibreOffice icons
I noticed that the menu was much slower around the Office submenu and that the LibreOffice icons are not the normal ones.

I opened the menu editor to remove every LibreOffice icons of the start menu and it now runs as it should, without slowdowns.
This is why I didn't get the slowdown while using the KFaenza icon theme: KFaenza has its own icons for LibreOffice and they are okay.

I also used gdb, but it showed the same thing as last time... Since it is not a bug in Kicker, it is of no interest here.

-Alexandre

One thing I forgot to write is that the reason the  whole Kicker menu took a lot of time to appear is that LibreOffice Writer was in the list of the most used programs.

-Alexandre

Alexandre,

Are the LibreOffice icons SVG?

There are two svg icons for each app. For example:

/usr/share/icons/hicolor/scalable/apps/libreoffice4.1-writer.svg
/usr/share/icons/gnome/scalable/apps/libreoffice4.1-writer.svg

Alexandre,
is this bug still happening?
I use the same icons (Crystal SVG) and don't see any problem with the menu, even with the LibreOffice icons.

> it takes sometimes, not all the time, 5-6 seconds before Kicker shows up
By Kicker do you mean specifically the TDE Classic menu? (I think so, from reading through the comments)
Is that "5-6 seconds delay" happening when you invoke the menu with the mouse or with Alt+F1? In the later case refer to bug 1733.

Hi,

The Kicker is the old, regular menu and KickOff is the newer one.
To let it appear, I click on it's icon on the TDE panel, but it is not supposed to behave differently of when it is run from the keyboard.


Yes, the problem is still there. It is related to how TDE R14 treats LO icons while using Crystal SVG icon theme on Ubuntu 13.04.

If LO is uninstalled, I do not get this slowdown. Also, with KFaenza icon theme, I don't get this slowdown.

Testing TDE R14 on slower systems is very important too.
This problem is probably not seen when it runs on a powerful computer.

Thank you!
-Alexandre

I have a PI and a PII, which are about as slow as they get nowadays. I will install LO and test CrystalSVG with both the Classic and Kickoff menus.

With both menus I do not see any slowdows on my dual core systems and I use CrystalSVG and LO on both.

Bear in mind that with the testing in bug 1733, we already know the PI and PII do not display the menus immediately like on modern multi-core systems. Therefore my testing baseline on the PI and PII will be the results from bug 1733. If the LO icons are causing problems then I should see a slowdown beyond what I saw in bug 1733.

> Testing TDE R14 on slower systems is very important too.
>This problem is probably not seen when it runs on a powerful computer.

Thanks for the feedback Alexandre. Just a quick question for info: are you using the latest GIT sources?


> I have a PI and a PII, which are about as slow as they get nowadays. I will
> install LO and test CrystalSVG with both the Classic and Kickoff menus.

Thanks Darrell, your tests will also be important

Hi,
My test machine is a first-gen Asus EEE 2G surf, the least expensive lappy on the market in circa 2008. It has a 571mhz Celeron and 512meg of RAM. Ubuntu runs on a 32gb SDHC card.

I am now re-installing it with Ubuntu 13.10
I will try to give feedback in the next few hours, or days.

The slowness I'm talking about is in comparison with the same computer, but running PCLinuxOS 2013 with TDE 3.5.13.2, so I am fully aware of of fast (or not that fast :) ) it should be.

-Alexandre

I should add that this CPU is about as fast as the last Pentium 3 that has been made. The I/O speed is not that great too.
-Alexandre

Hi,

I re-tested it, now on Ubuntu 13.10, TDE R14 of today and my first-gen Asus EEE.

The problem is with the LO icons. Just hovering the ''Office'' category freezes the system for half a minute on a slow computer. Uninstall LO or just remove the LO entries in the menu and everything is okay.

-Alexandre

I tested the LO icons on my PI and PII with the CrystalSVG icon set.

Scrolling through the menus on either system is painful even with LO not installed, as reported in bug 1733. With LO installed I noticed no difference in menu response.

I also tested with the KDE Classic ion set. Same basic response times with no noticeable difference with the LO icons.

I flushed the tdesycoca cache and restarted Trinity before each test.

In my libreoffice4.1-writer.desktop file, Icon=libreoffice4.1-writer. Searching my system for that file name string reveals the following image files:

/usr/share/icons/hicolor/scalable/apps/libreoffice4.1-writer.svg
/usr/share/icons/hicolor/16x16/apps/libreoffice4.1-writer.png
/usr/share/icons/hicolor/256x256/apps/libreoffice4.1-writer.png
/usr/share/icons/hicolor/32x32/apps/libreoffice4.1-writer.png
/usr/share/icons/hicolor/128x128/apps/libreoffice4.1-writer.png
/usr/share/icons/hicolor/48x48/apps/libreoffice4.1-writer.png
/usr/share/icons/gnome/scalable/apps/libreoffice4.1-writer.svg
/usr/share/icons/gnome/16x16/apps/libreoffice4.1-writer.png
/usr/share/icons/gnome/256x256/apps/libreoffice4.1-writer.png
/usr/share/icons/gnome/32x32/apps/libreoffice4.1-writer.png
/usr/share/icons/gnome/128x128/apps/libreoffice4.1-writer.png
/usr/share/icons/gnome/48x48/apps/libreoffice4.1-writer.png
/usr/share/icons/locolor/16x16/apps/libreoffice4.1-writer.png
/usr/share/icons/locolor/32x32/apps/libreoffice4.1-writer.png

On my system, the file size for the two svg images indicate the same file copied to different locations:

-rw-r--r-- 1 root root 545985 Oct 22 13:58 /usr/share/icons/hicolor/scalable/apps/libreoffice4.1-writer.svg
-rw-r--r-- 1 root root 545985 Oct 22 13:58 /usr/share/icons/gnome/scalable/apps/libreoffice4.1-writer.svg

A threading, svg parsing, or Ubuntu packaging problem?

Ok, now I'm in Konqueror, browsing /usr/share/icons/hicolor/scalable/apps
These are all SVG icons and the previews are not very fast to appear, maybe 1 or 2 seconds by icons. But, the libreoffice icons takes 30 sec - 1 minute to appear, and this time is needed by each libreoffice icons. The problem is probably with the SVG module.

Darrell, which distro do you use for your tests?

-Alexandre

Created attachment 1726 [details]
lo-icons-ubuntu1310-tder14

>Darrell, which distro do you use for your tests?
Slackware 14.0.

>The problem is probably with the SVG module.
My guess too. Even on my dual core system opening or viewing any of the LO svg icons takes a few seconds. All other svgs open immediately. As svg files are XML (text) files, I'll post a query on the dev mail list for one of the svg experts to inspect the files.

KFaenza icon set comes with its own icons for LO so, since the SVG icons are not used, the problem is not seen.

This is probably a regression in the SVG module performance, because this problem is not seen on TDE 3.5.13.2 on PCLinuxOS 2013, even on the same slow computer.

-Alexandre

Darrell, it would be interesting if you could try the KFaenza icon theme on your P1 or P2, to see if the menu is as slow.

Here is the URL:
http://kde-look.org/content/show.php/KFaenza?content=143890

Or, if you have one of my LiveCDs at home, you can use the files in:
/opt/trinity/share/icons

-Alexandre

>This is probably a regression in the SVG module performance, because this
>problem is not seen on TDE 3.5.13.2 on PCLinuxOS 2013, even on the same slow
>computer.
I don't have 3.5.13.2 on the PI or PII (but that's a good idea for comparative testing). I have 3.5.13.2 on a dual core laptop. I concur that viewing the LO icons is snappier in 3.5.13.2 than in R14. Not by a landslide, but noticeable.

>it would be interesting if you could try the KFaenza icon theme on
>your P1 or P2, to see if the menu is as slow.
I'll look.

>Or, if you have one of my LiveCDs at home
Links?

>it would be interesting if you could try the KFaenza icon theme on
>your P1 or P2, to see if the menu is as slow.
I tried the icon set. No noticeable gain. Not bad looking though. :-)

> Ok, now I'm in Konqueror, browsing /usr/share/icons/hicolor/scalable/apps
> These are all SVG icons and the previews are not very fast to appear, maybe 1
> or 2 seconds by icons. But, the libreoffice icons takes 30 sec - 1 minute to
> appear, and this time is needed by each libreoffice icons. The problem is
> probably with the SVG module.

> My guess too. Even on my dual core system opening or viewing any of the LO svg
> icons takes a few seconds. All other svgs open immediately. As svg files are
> XML (text) files, I'll post a query on the dev mail list for one of the svg
> experts to inspect the files.

I also see a noticeable delay in displaying the LO icons in /usr/share/icons/hicolor/scalable/apps and the computer fan goes crazy for a while. Though I have no delay in the TDE office submenu.
One thing to note is that those LO icons are quite big, >500 KB.

Definitely something we need to look into.

Here is the link to my LiveCD:
http://www.trinitydesktop.org/wiki/bin/view/Documentation/LiveCDs

It is tested to work even with 256mb of RAM, on a P3. Once installed, it could work on even as low as 128mb of RAM, but much slower. It will boot on a P2, but not on a P1, because kernel is i686. On the boot menu of the LiveCD, you can choose ''Install PCLinuxOS''. This option boots straight to the installer, without loading the desktop, so it could work with even less RAM.
Login info:    user:guest     password:guest

I remember having used PCLinuxOS 2007 (Kde 3.5.9?) often on my old 2-inch-high Compaq Armada 1700 (P2-233mhz - 160mb RAM) and the menu was very quick to appear, so you have probably found another bug.

-Alexandre

>One thing to note is that those LO icons are quite big, >500 KB.
I noticed too. Perhaps when we resolve the Trinity side we could ask a graphics guru (there are one or two in the Trinity community) to resize those icons and submit upstream.

At a fist level, the first easy patch to do would probably be to put bitmap icons of LO in the Crystal SVG folders. The way icon themes works is to check first in the icon theme folders, and only if the icon is not there, it goes in the hicolor folder to get the icon. By placing raster icons of LO in the Crystal SVG folder, this problem is avoided.

The next thing to look at is why TDE still use an old SVG module, when other libraries are much faster for displaying SVG pictures. KDE4 and GNOME uses the same icons and they appear almost instantly, even on an old computer.

Just to make a test, on my old Asus EEE, I opened the LO icons folder in the GNOME file manager (is it still called nautilus on GNOME 3 ?), while being on TDE, and the previews appears much faster on the screen than browsing in with Konqueror.

-Alexandre

>The way icon themes works is to check first in the icon theme folders,
>and only if the icon is not there, it goes in the hicolor folder to
>get the icon. By placing raster icons of LO in the Crystal SVG folder,
>this problem is avoided.
I like this idea, but a notable challenge is the LO desktop files Icon= key all reference the image by version number. For example, Icon=libreoffice4.1-base. Every time LO is updated to a new version, the referenced file name will change in all desktop Icon= keys, which will render obsolete any png images we create. LO is too fast a moving target to keep pace with png icon file updates. We can't rename the png icons to a generic name, such as libreoffice-base.png because the desktop file Icon= keys won't point to those image files.

Because many distro releases remain relatively static other than security updates, such as Debian releases, we would need many LO png icons to support the many past and future LO releases.

The maintenance required to support png images in Trinity would be overwhelming. :-(

>The next thing to look at is why TDE still use an old SVG module, when other
>libraries are much faster for displaying SVG pictures. KDE4 and GNOME uses the
>same icons and they appear almost instantly, even on an old computer.
This seems the best solution.

The LO images are obscenely huge, but if new rendering algorithms are solving the problem then let's adopt those methods.

Perhaps a knowledgeable Trinity user/developer who understands svg file formats could contact the LO developers and ask them to create svg icons that are less complex and more suitable for older rendering software and hardware. There is no good reason to have 1.1 MB svg files. Considering svg files are text based XML files, that kind of file size is huge.

If I remember well (can you confirm it?), keeping multiple versions of icon files is the way it works for KFaenza icon theme. It works well, but as you say, it will eventually have its troubles...

-Alexandre

Yes, looks like the maintainer did that with some apps.

The LO package I'm using comes with png files of the svg icons. A possible short-term hack suggested in the dev mail list is to add code to ignore LO svg icons. Long term we should adjust the svg algorithms to something more modern.

Hi,

Maybe, for the moment, symlinks with different version number could be created to point the right PNG icon, copied in the Crystal SVG folder.

It wouldn't be too long to create symlinks for a few version numbers like this:
4.1
4.2
4. ...
4.9
5.0
5. ...
That way, it would be good for a few years, until something better is found.

-Alexandre

Sorry for the late reply, I have been busy.
IMO we should do both things:
1) improve the svg handling software in TDE (perhaps looking at how Gnome/KDE4 handles that)
2) replace the LO icons used in the TDE menu with simpler icons