KMountPoint::probablySlow and cifs mount points

[Albert Astals Cid]

El Dilluns, 25 de novembre de 2013, a les 20:26:23, Ingo Klöcker va escriure:
> On Monday 25 November 2013 00:12:34 Albert Astals Cid wrote:
> > El Dilluns, 25 de novembre de 2013, a les 00:01:41, Mark Gaiser va
> 
> escriure:
> > > On Sun, Nov 24, 2013 at 10:09 PM, Albert Astals Cid <aacid at kde.org>
> 
> wrote:
> > > > El Diumenge, 24 de novembre de 2013, a les 19:42:25, Mark Gaiser
> > > > va
> > 
> > escriure:
> > > >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid
> 
> <aacid at kde.org> wrote:
> > > >> > In Okular we just got bug
> > > >> > https://bugs.kde.org/show_bug.cgi?id=327846
> > > >> > PDF Render time is unreasonably slow over cifs on high latency
> > > >> > (WAN)
> > > >> > network connections
> > > >> > 
> > > >> > Basically the issue is that poppler is quite read-intensive
> > > >> > over files, reading them over and over, and since the file is
> > > >> > "local but really remote" it takes ages to render for big
> > > >> > files.
> > > >> > 
> > > >> > The only solution i can think of is doing a local copy and then
> > > >> > working on
> > > >> > that.
> > > >> 
> > > >> That would work with small files (< 10 MB) but will get you into
> > > >> trouble for bigger files.
> > > > 
> > > > Why?
> > > 
> > > See my example below.
> > > 
> > > >> You can't - or shouldn't - do that in an automated manner. If the
> > > >> user manually copies the file and then opens it in a pdf reader:
> > > >> fine. Just don't auto copy the file. So you can probably give
> > > >> the user a popup suggesting them to copy the file to his local
> > > >> drive?
> > > > 
> > > > Why? If you open a huge file by smb:// it'll copy it to the local
> > > > file anyway, so why should not we copy it?
> > > 
> > > Right. True but should it be like that?
> > > Lets take playing a movie from smb as an example. If you do that now
> > > in for example mplayer then kde will simply copy the movie to your
> > > local drive and start playing it. But should that be the case? I
> > > consider it a massive usability bug. One that isn't easy to fix. If
> > > you would mount the same share as cifs then the system "thinks" it's
> > > local and just plays the movie without copying.
> > > 
> > > That is how it should be. Copying to your local system is a nasty
> > > workaround which should imho be prevented.
> > 
> > A PDF file is not a movie, it can't be read lineraly.
> 
> Does the PDF format really prevent me from reading just the first 2
> pages of a 100 pages document if I just download the first few KBs of
> the PDF file? I don't know the PDF format, so this question is serious.

It [mostly] does. The XRef (table that references everything else on the file) 
is at the end of the file. So we need that, of course in protocols like CIFS 
we can just read the end of the file without downloading it all. But that 
still leaves us with objects that reference eachother all over and unless the 
file is specially crafted (so called Linearized PDF) it'll mostly be "the 
whole file", so no you don't need *always* the whole file, but you mostly do.

> If the answer to the question is no, then it does make a lot of sense to
> load the file iteratively. For example, if I just want to have a quick
> look at the document (e.g. the abstract on the first page) to decide
> whether it's really the document I am looking for, then I surely don't
> want to wait for the entire document to be downloaded.

Yes, that can be done, as it is my plan, but still will need to download the 
whole file most of the times.

Cheers,
  Albert

> 
> 
> Regards,
> Ingo