Ristretto crawls to a halt on USB1.1 file systems

[David Kastrup]

I often hook up my camera with a USB cable, and it's USB 1.1. I can browse fine (including thumbnails), and I can copy files over with useful speed ("full speed"). But whenever I start Ristretto on such a file, I have to eventually kill it because it never comes back in time. The access on the camera is on while Ristretto hangs, so presumably it is doing something that causes it to reread the same information unbuffered again and again or doing something else that is very, very inefficient on a file system mounted via USB (reading bytewise and adjusting the access time every time?).

Here is the camera description:
Bus 005 Device 023: ID 054c:0010 Sony Corp. DSC-S30/S70/S75/F505V/F505/FD92/W1 Cybershot/Mavica Digital Camera
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x054c Sony Corp.
  idProduct 0x0010 DSC-S30/S70/S75/F505V/F505/FD92/W1 Cybershot/Mavica Digital Camera
  bcdDevice 4.50
  iManufacturer 1 Sony
  iProduct 2 Sony DSC
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 39
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xc0
      Self Powered
    MaxPower 2mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 3
      bInterfaceClass 8 Mass Storage
      bInterfaceSubClass 255
      bInterfaceProtocol 1
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x01 EP 1 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x83 EP 3 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 255
Device Status: 0x0001
  Self Powered

Here is the mount entry:
/dev/sdd1 on /media/dak/8867-BE11 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

This is a reasonably straightforward amd64 Ubuntustudio installation.

All other basic utilities and operations on that "drive" provided by the camera are reasonably fast and corresponding to what you can expect from "full speed" USB 1.1.

But Ristretto is unusable. It needs to do something differently when reading files: this just doesn't work. I've never seen fit to let it complete but rather killed it after a few minutes.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: ristretto 0.8.2-1
ProcVersionSignature: Ubuntu 4.12.0-11.12-lowlatency 4.12.5
Uname: Linux 4.12.0-11-lowlatency x86_64
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon Aug 28 10:49:16 2017
InstallationDate: Installed on 2011-10-14 (2144 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111011)
SourcePackage: ristretto
UpgradeStatus: No upgrade log present (probably fresh install)

[Theo Linkspfeifer (lastonestanding)]

Is this still the case in 18.04 or 18.10?

[David Kastrup (dak)]

It is still the case in 18.10 and it even happens on USB2.0 or even image directories on the internal SSD drive. From the visual appearance, I suspect on-the-fly thumbnail generation for the side bar to be at fault. It should likely be made to happen in its own thread or process without the main image viewer waiting for its completion.

[David Kastrup (dak)]

To put a perspective on a "best implementation" perspective: in the WYSIWYG LaTeX rendering environment "preview-latex" on Emacs, the strategy was to place all unrendered images of a document (corresponding to Ristretto's file lists) in a list and feed a queue with something like 4 places from that list. However, if there were any _on-screen_ unrendered images, those were fed into the rendering queue in preference. This strategy resulted in stable working screens fast even when it took a minute for a whole document to have its images rendered in background and leafing back and forward uncovered unfinished work momemntarily during that time.

We are talking about rendering with Ghostscript here, on 200MHz Pentium processors.

So if a strategy like that could be made to work smoothly for Emacs+Ghostscript, a quite slower combination on a quite slower processor, it should work well enough for something like Ristretto. Maybe there are even frameworks/libraries catering to most of that task.

[Theo Linkspfeifer (lastonestanding)]

If the thumbnail generation is to blame for the slowness, then it should work faster after disabling the thumbnail bar I would assume. Can you confirm that?

Furthermore, I suggest that you forward this bug to the Xfce bug tracker, so that the upstream developers can look into this and your proposed solution.

https://bugzilla.xfce.org/

[David Kastrup (dak)]

Good call, but disabling the thumbnail bar doesn't help with the startup time, either when starting by double-clicking on a file in the file manager or by starting it on the command line (with a directory name).

[Launchpad Janitor (janitor)]

[Expired for ristretto (Ubuntu) because there has been no activity for 60 days.]