-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody,
as I was the one to find the bug in the first place, I did some quite extensive testing with Adam today and in the current trunk revision prefetching seems to work just fine for me. I tested with a standard latex output file without images and with a very large file consisting almost exclusively of images, and so far no problems have occured. Memory usage also seems to be fine. I tried some different display sizes and the presentation view. Still it would be great, if some of you could do some additional testing, to be sure. Best Regards, Benjamin > Hello, > > Because I was asked to do explain this in a bit more detail, I'll > try: > > On 24.07.2012 19:20, Adam Reichold wrote: >> Hello, > >> Something unpleasant happened: Someone testing the current trunk >> revisions reported reproducible race conditions in the current >> rendering code when prefetching is enabled. After some >> consideration, I redid almost all threading involved and changed >> it to a more robust signals-based design. (The alternative was to >> remove prefetching.) > > Race conditions in this case means, that pages were not rendered > because prefetching was canceled... But prefetching is not supposed > to be cancellable... (By design, so to speak.) But if prefetching > finishes, and a new rendering starts before the results of > prefetching are dispatched and the rendering is canceled, then the > result of a canceled rendering - an invalid empty image - is > stored in the cache as a (supposedly valid) prefetching result. > > So the problem is that the correct functioning depends on the > ordering of operations performed in different threads which are > executed in parallel. Usually, this should not happen as the > programmer should have taken care to avoid such ordering > dependencies via locking or similar mechanisms. If not done > correctly, the threads sometimes "race" to fulfil some strange > condition that leads to incorrect function... > > In this case, I used a simple lock-less design utilizing that > QImages are actually atomic pointers to implicitly shared data, but > my state handling got completely screwed by introducing prefetching > and after fixing the memory management bug Sandor reported, it got > even more complicated. So I more or less redid it. Not depending on > a lock-less design but letting Qt signals and slots handle the > passing of data between threads. This could lead to a higher memory > usage if not done correctly. Hopefully I did not screw up this > time. > > Practically, this meant that some pages were just not rendered if > prefetching was enabled and the scrolling was timed correctly. > (Rather hard to reproduce, but possible.) They were rendered after > zooming in or out and if they were actually visible, i.e. when > prefetching was not involved. > > Currently, after the latest changes, everything should be fine and > working as expected with a simpler code base. But it is just so > late in the development cycle that I chose to issue a third beta of > version 0.3.2. Hence the need to test for rendering and memory > management problems. Especially with respect to the different view > modes like continuous and also the presentation view. > >> This should improve the robustness of rendering resp. threading, >> but this close to releasing version 0.3.2, I am very >> uncomfortable with such a intrusive change. So if you have some >> spare time on your hands, please test any version newer than >> trunk revision 476 concerning rendering, prefetching and - >> connected to that - memory consumption. > >> Thank you for your help! Best regards, Adam. > > > Best regards, Adam. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQECSDAAoJEK27BRz67lmp1qEP/1oDEOaBcqGDoRRCm60waqnF 0WeZ6tjS8VxH2RWnVBcSFRfTI9Czz1hw9d5k5LohBs6ZmkwGOunYg0djwb8g9uK6 wxw8yEnInGJCZCZ+G4RKv/hkMNMAr6tfrzCOPTzZZUjszD0lfqjISQb7Siwzh0uq 2gzAP6nKi//be4ZeKs8hmo4T4qwV05QuVyv5MSVKRtdk6wW/0FkX8ALWFbC0hxZM +dSCjg68zzsPYkq4VUBqVJeCVlKKG4VNQJfJ2m3ft0tRZx52idZuGguM0A7F6pEQ ssMjdyOBUrccATRjaHKh3ZwCVSebY4fZSoqly6KjQD3sf8MblWjP1T5+kSJf/AhB c7YSdxwUYRCAHSCr/bhkAZzY21AsQ/8wKU1m7SE/XifzoooNcJMIOPUBZc7rPTK5 PMd8M1jDf6YbkPdgQpQ5PraQoLP0wZBmwzY0FtNni0TbJWA5xuFCqfH8XG8yhOc7 42I1FEZz4W9KJ5Ud+MWaTIhznwwv53zdW/DLpH1VdA7V/cEFiXz/+r1FJHkdwMUt zwxle/H4/WdIILi6vrl0L5sDGj56iG2ItxFfT1AMtFWJGPkX7ghmolj3ocesYV3D dU1XdN3NufWvmDn0DAhvVumOVZ8+KLUtK5Y0GoGEpGTCSyO4ZLGJ0cJgPgr+rdrk vcs4eQ1UKaTEUqW//kOM =DPzN -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~qpdfview Post to : [email protected] Unsubscribe : https://launchpad.net/~qpdfview More help : https://help.launchpad.net/ListHelp
