| Summary: | Picture Frame Widget Freezes Plasma-desktop | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Zachary Klein <zak> |
| Component: | widget-frame | Assignee: | Anne-Marie Mahfouf <annma> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dusdus, turtle, xeros |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
||
I also should mention that Ive been using Picture Frames to display remote images since KDE 4.2; this is the first time I've noticed this issue (I can't garrantee that it wasn't happening before, but I doubt it). I'm expecting the same behaviour on two machines which I've upgraded to KDE 4.4 but the pictures folders are on local ext3 and ext4 filesystems. Picture Frame with changing images is unusable in KDE 4.4.0. And that's on Kubuntu 9.10 with KDE 4.4 upgrade from kubuntu-ppa/backports repository. And I don't have many pictures in folders (~100 images+videos) and everything there is indexed with Nepomuk+Strigi. (In reply to comment #0) > Version: (using KDE 4.4.0) > OS: Linux > Installed from: openSUSE RPMs > > I am using a pair of Picture Frame widgets to display a slideshow of images > froma remote Samba share. While loading the image ( > KExiv2Iface::KExiv2::getImageOrientation), the entire plasma-desktop freezes, > taking longer (up to 20 seconds) if the image requires the frame to resize > ("ItemSpace::resizeItem"). Since displaying remote pictures is a fairly common > use case, shouldn't widgets like Picture Frame be able to wait for their > response witrhout freezing the entire desktop? > > I understand that there may be technical issues with this, but a 20 second > freeze in the desktop surely isn't acceptable, is it? I'm having exactly the same issue, while using kde 4.4 un kubuntu (using the backports repository). I'm not using the PictureFrame though. I'm using the wallpaper slideshow. After disabling this feature the hicups were gone. The wallpaper changed every 2 minutes, the hicups I got every 15 seconds or so. Tomasz and Zachary: same on desktop slideshow mode with same pictures folders and settings than Picture Frame? The desktop slideshow (using a remote image source) doesn't cause plasma-desktop to freeze. It has it's own problem - an annoying workaround that preloads a bunch of images every minute or so (with an "in-your-face" dialog box to let you know all about it!). But no, it doesn't seem to cause this issue to come up. Is this still valid please? Created attachment 65188 [details]
New crash information added by DrKonqi
plasma-desktop (0.4) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4
- What I was doing when the application crashed: I was adding one more widget on the desktop while the widget that caused the crash has just been edited with a new picture url and was updating/downloading the picture
- Unusual behavior I noticed: The desktop froze then re-started, the widget updated afterwards
-- Backtrace (Reduced):
#7 0x004c05cb in QByteArray (a=..., this=0xbf92edb0) at /usr/include/qt4/QtCore/qbytearray.h:421
#8 KIO::StoredTransferJob::data (this=0xa97dd48) at ../../kio/kio/job.cpp:1708
#9 0x0298d586 in Picture::slotFinished (this=0x9c24c10, job=0xa0d39f8) at ../../../applets/frame/picture.cpp:148
#10 0x0298df95 in Picture::qt_metacall (this=0x9c24c10, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xbf92ef18) at ./picture.moc:82
#11 0x08d35b7d in metacall (argv=0xbf92ef18, idx=5, cl=QMetaObject::InvokeMetaMethod, object=0x9c24c10) at kernel/qmetaobject.cpp:237
Created attachment 65221 [details]
New crash information added by DrKonqi
plasma-desktop (0.4) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4
- What I was doing when the application crashed: Editing the properties of one of the picture frames while another was in the process of updating the picture (all pictures are fetched from the net and not stored locally)
-- Backtrace (Reduced):
#7 0x004a65cb in QByteArray (a=..., this=0xbffc35b0) at /usr/include/qt4/QtCore/qbytearray.h:421
#8 KIO::StoredTransferJob::data (this=0x9e06b78) at ../../kio/kio/job.cpp:1708
#9 0x0816c586 in Picture::slotFinished (this=0x9612a70, job=0xa58b9a0) at ../../../applets/frame/picture.cpp:148
#10 0x0816cf95 in Picture::qt_metacall (this=0x9612a70, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xbffc3718) at ./picture.moc:82
#11 0x08497b7d in metacall (argv=0xbffc3718, idx=5, cl=QMetaObject::InvokeMetaMethod, object=0x9612a70) at kernel/qmetaobject.cpp:237
Created attachment 65431 [details]
New crash information added by DrKonqi
plasma-desktop (0.4) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4
- What I was doing when the application crashed:
I was opening the setting dialog of my picture widgets so as to force them to update upon closing the dialog. At the same time, I attached a USB hub but as this went undetected by Kubuntu, I doubt it had any influence.
-- Backtrace (Reduced):
#7 0x001d05cb in QByteArray (a=..., this=0xbfe0f0d0) at /usr/include/qt4/QtCore/qbytearray.h:421
#8 KIO::StoredTransferJob::data (this=0xa6efc20) at ../../kio/kio/job.cpp:1708
#9 0x054a3586 in Picture::slotFinished (this=0x9caf6b0, job=0xa8b3600) at ../../../applets/frame/picture.cpp:148
#10 0x054a3f95 in Picture::qt_metacall (this=0x9caf6b0, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xbfe0f238) at ./picture.moc:82
#11 0x06147b7d in metacall (argv=0xbfe0f238, idx=5, cl=QMetaObject::InvokeMetaMethod, object=0x9caf6b0) at kernel/qmetaobject.cpp:237
Created attachment 65508 [details]
New crash information added by DrKonqi
plasma-desktop (0.4) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4
- What I was doing when the application crashed:
Refresing one of the 5 picture widgets on the dewstop (pressing ok, to close the widget settings)
-- Backtrace (Reduced):
#16 0x021e9d82 in makeSpace (where=QIODevicePrivateLinearBuffer::freeSpaceAtEnd, required=<optimized out>, this=0x9542b50) at io/qiodevice_p.h:173
#17 reserve (size=16384, this=0x9542b50) at io/qiodevice_p.h:114
#18 QIODevice::read (this=0xbfd0ea88, data=0xbfd0e766 "\177\t\006", maxSize=6) at io/qiodevice.cpp:824
#19 0x033837df in readIconDir (iodev=<optimized out>, iconDir=0xbfd0e7a8) at qicohandler.cpp:184
#20 0x033839ca in ICOReader::canRead (iodev=0xbfd0ea88) at qicohandler.cpp:272
@turtle please indicate clear steps to reproduce: what settings you use and what images you display for each picture frame (example of an URL that makes it crash) and how to trigger the crash. @Zachary and Tomasz: the widget has been highly optimized thanks to Aaron Seigo work! Git commit 2967918a990524b7e85e9cd6928e10ad4fe17b5f by Aaron Seigo. Committed on 03/12/2011 at 12:43. Pushed by aseigo into branch 'master'. don't hold on to the job pointer, it gets passed back to us in the completion slot BUG:227394 M +4 -4 applets/frame/picture.cpp M +0 -1 applets/frame/picture.h http://commits.kde.org/kdeplasma-addons/2967918a990524b7e85e9cd6928e10ad4fe17b5f |
Version: (using KDE 4.4.0) OS: Linux Installed from: openSUSE RPMs I am using a pair of Picture Frame widgets to display a slideshow of images froma remote Samba share. While loading the image ( KExiv2Iface::KExiv2::getImageOrientation), the entire plasma-desktop freezes, taking longer (up to 20 seconds) if the image requires the frame to resize ("ItemSpace::resizeItem"). Since displaying remote pictures is a fairly common use case, shouldn't widgets like Picture Frame be able to wait for their response without freezing the entire desktop? I understand that there may be technical issues with this, but a 20 second freeze in the desktop surely isn't acceptable, is it?