Version: (using 4.1.3) Installed from: Debian testing/unstable Packages avoid white pages as progress indicators Currently when you go from page (A) to page (B), you won't see a sequence A -> B but A -> white page with okular logo -> B On fast (?) computer it leads to flickering and after some time it hurt the eyes, so please only two pages. A -> B. If you insist that showing okular logo is a must, please show it embedded within A image (probably in the center, it is more visible than the corner), and then immediately page B. I know it looks like a wish, but in fact it closer to a bug, because of the health impact it has -- when I go somewhere page 80, but I don't remember exactly, maybe 60, or 100, I won't see 40 pages, but 80 pages (40 actual, 40 artificial). Bottom line is: flickering is bad in medical terms. Please remove it. (*) note on logo placement, every place is disputable, but to notice something in the center it is easier to user to "read" it, with corners, it is slow enough to notice it, but too fast to read it, thus it is distraction "what was that, get back". Of course there is nothing "get back", because it is artificial interruption.
The Okular logo is there to indicate that a page is being rendered, not because of some sort of fun. Also, I don't see how it would be of so harm, given also that it is a) in a corner b) small (48px), so if you scroll you have good chances to not even see it. Please then suggest something then, keeping into account that: a) already generated and shown pages must NOT be touched (because it would be wrong to show changes for them, while there are not) b) tells people a page is being rendered c) white pages can really exist in the document, so showing white pages is NOT an option either > (*) note on logo placement, every place is disputable, ... so avoid disputating it? :) Thanks.
> > (*) note on logo placement, every place is disputable, > ... so avoid disputating it? :) Thanks. I explained the reasons for the change. ad.a) I don't understand this assumption, if you zoom out/in page the page "changes" while in fact it does not change ad.b) sure, visual indicator matters -- however it leads to flickering, because on fast computer it makes more harm than good, take a look at KDE, by default you have visual indicators, but you can turn them off ad.c) white page is an option at all -- it hurt eyes Pino, it it not about okular logo (1% of the issue), it is about this extra white page (99%). So, suggestions: 1) remove white pages at all. 2) provide visual feedback (okular logo) by default with ability to turn it off 3.1) in (a) really holds -- use mouse cursor, it is standard way to show "busy, computations" 3.2) if (a) is not that serious (in my opinion is not) I see a lot of splashscreens, logos, etc. and I never thought it had any impact on the data, show just okular logo at the current page, then switch to target page 3.3) since bottombar is set on by default it could be a place (even with progress bar) to show logo as activity indicator
What you are asking is something you don't want. You want okular to be synchronous, that is, do not display a page until it's totally rendered, to achieve that simply disable background generation in the options and see how much it sucks.
(In reply to comment #2) > ad.a) I don't understand this assumption, if you zoom out/in page the page > "changes" while in fact it does not change You didn't get me. Zooming of course does not change the page, but artificially adding a logo does. > ad.b) sure, visual indicator matters -- however it leads to flickering, because > on fast computer it makes more harm than good, take a look at KDE, by default > you have visual indicators, but you can turn them off "fast computer" is a poor working. You can have documents whose pages will take SECONDS even on "fast computers". > ad.c) white page is an option at all -- it hurt eyes It is not an option. > So, suggestions: > 1) remove white pages at all. And what do you do instead? Block the user interface because you have nothing to show? Show an hole? No, rejected. > 2) provide visual feedback (okular logo) by default with ability to turn it off I don't want Okular as the paradise of options. Rejected. > 3.1) in (a) really holds -- use mouse cursor, it is standard way to show "busy, > computations" The point of showing *something* for non-rendered-yet pages is to make the user interface active. A busy cursor just show some animation and no cursor at all, so it gives the false idea the whole UI is frozen. Rejected. > 3.2) if (a) is not that serious (in my opinion is not) I see a lot of > splashscreens, logos, etc. and I never thought it had any impact on the data, > show just okular logo at the current page, then switch to target page Currently shown pages won't be changed. Rejected. > 3.3) since bottombar is set on by default it could be a place (even with > progress bar) to show logo as activity indicator So you (also) want to make the bottom bar optional, and then putting "vital" information there, so there will be a crowd of people asking for another place for that becuase they disabled the bottom bar? Sorry, no. Rejected. *Every* document reader out there shows white pages while rendering them and not blocking the UI, this is a well known behaviour. Given that we cannot know how fast a page can be rendered, Okular also shows a very small (48px) icon to indicate the rendering is being done.
(In reply to comment #4) I agree with most of what you say, Pino, except for this one: > A busy cursor just show some animation and no cursor at all, so it gives the > false idea the whole UI is frozen. IMHO this depends on the type of busy cursor used. It is certainly true for a standard hourglass or clock type busy cursor, but it is not true for the type I have seen in some parts of KDE4, where the standard arrow cursor is just augmented by a rotating object. What I don't know is if these cursors are actually a different type or just a result of theming. Cheers, Jochen
@Pino, > > ad.a) I don't understand this assumption, if you zoom out/in page > > the page "changes" while in fact it does not change > > You didn't get me. Zooming of course does not change the page, but > artificially adding a logo does. I meant, visually adding. Not changing the image itself. So in this sense adding logo does the same effect, as zooming. > > ad.c) white page is an option at all -- it hurt eyes > > It is not an option. Yes, my typo -- it should be: is *not* an... > > So, suggestions: > > 1) remove white pages at all. > > And what do you do instead? > Block the user interface because you have nothing to show? > Show an hole? > No, rejected. You said above that showing white pages is not an option. We are talking about those artificially created objects, not white pages from pdf! > > 2) provide visual feedback (okular logo) by default with ability > > to turn it off > > I don't want Okular as the paradise of options. > Rejected. I forgot, all users are the same. > > 3.1) in (a) really holds -- use mouse cursor, it is standard way > > to show "busy, computations" > > The point of showing *something* for non-rendered-yet pages is to > make the user interface active. > A busy cursor just show some animation and no cursor at all, so it > gives the false idea the whole UI is frozen. Not at all, there are two kinds of busy cursor. Besides, changing cursor shape does not change the UI activity. > *Every* document reader out there shows white pages while rendering > them and not blocking the UI, this is a well known behaviour. Hurray, every other document readers strain the eyes, lets follow the path. What kind of thinking is that? If everybody makes a mistake, and huge one, because somebody's health cannot be taken lightly, you are opposing, because it is better be in the crowd? @Albert, > What you are asking is something you don't > want. ? > You want okular to be synchronous, that is, do not display a page > until it's totally rendered, to achieve that simply disable > background generation in the options and see how much it sucks. ? I don't get it -- I just want to remove the extra page between which was generated artificially on the fly, which causes flickering effect. That's all. Albert, if it would be removed, with no option changed, I would simply see x2 less pages, I would see page A longer, and then page B. Big relief for the eyes.
(In reply to comment #6) > I meant, visually adding. Not changing the image itself. And again, it changes the image, meant as "what the user sees". Imagine some logo popping up in a renderer page, wouldn't this surprise the user? "wft? the page changed?". > You said above that showing white pages is not an option. We are talking about > those artificially created objects, not white pages from pdf! They are *NOT* articifically created objects, they are *pages* of the document! They do have the proper size, the proper objects on them (like annotations, form fields, etc)... just they have not been rendered yet, or they need to be rendered again. > > *Every* document reader out there shows white pages while rendering > > them and not blocking the UI, this is a well known behaviour. > > Hurray, every other document readers strain the eyes, lets follow the path. > > What kind of thinking is that? If everybody makes a mistake, and huge one, > because somebody's health cannot be taken lightly, you are opposing, because it > is better be in the crowd? That's not the point. The point is: if that would be a so huge problem, wouldn't that be solved already since years? The behaviour model is well tested and working fine. > ? I don't get it -- I just want to remove the extra page between which was > generated artificially on the fly, which causes flickering effect. Again, there is nothing extra. What you see is *your* document.
> > I meant, visually adding. Not changing the image itself. > And again, it changes the image, meant as "what the user sees". > Imagine some logo popping up in a renderer page, wouldn't this > surprise the user? "wft? the page changed?". I didn't see such reaction at all. Not only for kpdf/okular but in general. Progress indicators are quite common now. > > You said above that showing white pages is not an option. We are > > talking about those artificially created objects, not white pages > > from pdf! > They are *NOT* articifically created objects, they are *pages* of > the document! They do have the proper size, the proper objects on > them (like annotations, form fields, etc)... just they have not > been rendered yet, or they need to be rendered again. So my wish is -- do not show them. Show only and only this what is in the document. Do not show in-between steps. (*) > The point is: if that would be a so huge problem, wouldn't that be > solved already since years? It was, over 20 years ago. The technique is called double buffering, you show one image, you render the second internally (not showing it), when it is ready, you show the second one. Ready to see. And besides, this logic is flawed -- "640KB is enough, who would need personal computer, etc etc etc." I heard it all. So if I follow this logic, we now need some move from Apple, and then everybody would say "oh, geniuses, how they spotted this?". > The behaviour model is well tested and working fine. Yes, it is well tested flickering is bad for eyes, but you are mistaken, it does not work fine. We are talking about health here. > Again, there is nothing extra. What you see is *your* document. Wrong. I see white pages, my document has zero white pages. I _WISH_ I would see _ONLY_ what is in my document. Only. (*) there is another approach, to show image blurry and then step by step in more quality. I don't mind this approach, because it does not affect eyes (that much) as flickering with white pages
PS. Of course, double buffering would rather lead to synchronous behaviour, while showing blurry image first, to asynchronous (in some degree). The first one was present in kpdf, and it was much easier for the eyes -- the only missing part was visual indicator of computation. User choices can vary in regard of asynchronous vs. synchronous, but I prefer to keep my health, thus more important for me is quality of the image, rock-stable, without flickering.
I am terribly sorry, I incorrectly copied the settings from kpdf.
Next time, please think twice before swearing on nonsense, please.
Of course, my mistake, I am terrible sorry. ( Side remark: please, do not accuse me of something that didn't take place, here swearing. Thank you. )