El Dilluns, 25 de novembre de 2013, a les 18:23:53, Mark Gaiser va escriure: > On Mon, Nov 25, 2013 at 5:41 PM, Aurélien Gâteau <agat...@kde.org> wrote: > > Le lundi 25 novembre 2013 13:54:38 Mark Gaiser a écrit : > >> On Mon, Nov 25, 2013 at 10:45 AM, Aurélien Gâteau <agat...@kde.org> wrote: > >> > Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a écrit : > >> >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aa...@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. > >> >> 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? > >> > > >> > I disagree with that: I believe the use should not have to worry about > >> > this > >> > and trust the application to be smart and do whatever is most > >> > appropriate > >> > to deliver the best result instead. > >> > >> No. Here's why (again, but more detailed). > >> 1. People don't expect the file to be copied. Just to be opened. > > > > Sure, the fact the file has been downloaded should not be exposed to the > > user, it should be downloaded in the background and removed afterward. > > Here you say the user should not be bothered. Later on you say there > should be some kind of process bar for the user to cancel.. > > >> 2. If you follow this route, you are already in the "probablySlow" > >> path thus it copies over a likely slow connection. Have you though > >> about the added bandwidth that takes? Not everyone is on unlimited > >> insanely fast internet lines. Some people have bandwidth caps. For the > >> record: i'm not one of those. > > > > I don't think users consider PDF files as streamable content that can be > > progressively read: it would make it impossible to do things like > > searching > > for text across the document: you need the whole document. People with > > bandwidth caps are aware of them and will download the file themselves > > before opening it. > > Sorry, but this is a moot argument. People very often don't know if > they have a bw limit or on what kind of connection they are. Not > everyone is as technical as you and me. > > >> 3. Copying it leaves the user puzzled as to where "the smart > >> application" might have copied the data to. > > > > Not if this is done transparently. > > > >> 4. Copying also slowly eats your disc space. When i had this nasty > >> surprise with a 10GB movie i wanted to play - not copy! - i was > >> welcomed by a disc full error.. > > > > You can't compare the use case of a movie and a PDF. A movie is something > > you expect to go through in one go. Arguably, you can also skip and go > > back and forth, but it is much easier with movies than with PDF because > > movie container formats were designed for that, and even with this > > design, it does not work well with all network file systems. > > > > As for disk space, it should be possible to check if there is enough disk > > space before downloading, but again movies and PDF are quite different: > > 10GB PDF may exists, but they are pretty much the exception. > > Yeah.. And that is exactly the reason why i use KDE's KIO less and > less to access network stuff. I - and i know the code! - don't even > know exactly when app X or Y starts do download a file before playing > it (mplayer) or just acts like it's bleeding and does nothing (dragon > player). I simply mount partitions manually if i'm about to access the > network for more then just browsing through folders. > > >> 5. And what if i open an PDF (in this example) just to see the first > >> page and then close it again. That is a needless copy. > > > > I assume the copy is temporary, it is removed once Okular is closed. > > Okular > > could start displaying the first pages while it is still downloading in > > the > > background. I have no idea if this is possible with PDF files. > > Oh fun.. So completely wasted bandwidth even. You can't seriously be > thinking that this is a good idea.
Well, the user opened the file, he's expecting the bandwidth to be used, no? I mean why would he open the file otherwise? And FYI the current implementation uses much more bandwitdh as I already explained on your post, so not sure you're defending the right position here if bandwith is your concern. Cheers, Albert