Multi-threaded image rendering
Moderators: TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Multi-threaded image rendering
Hello everyone!
Is there any chance to get multi-threaded image rendering in Editor? Currently it seems to render images using a single thread, or maybe two which are not fully utilized. There is little difference between asynchronous and synchronous mode. Full page A3 images can take several seconds to render, I can even watch them being built up. Meanwhile 90% of my CPU (8 cores / 16 threads) remain unused.
I tried to manually set rendering thread count to 8 and total count to 16, just in case that the automatic setting might be the problem, but to no avail.
Is there any chance to get multi-threaded image rendering in Editor? Currently it seems to render images using a single thread, or maybe two which are not fully utilized. There is little difference between asynchronous and synchronous mode. Full page A3 images can take several seconds to render, I can even watch them being built up. Meanwhile 90% of my CPU (8 cores / 16 threads) remain unused.
I tried to manually set rendering thread count to 8 and total count to 16, just in case that the automatic setting might be the problem, but to no avail.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Related to this: Does the "Do not use disk to cache decoded images" option do anything? Or rather, should I see a difference when it's not enabled (by default)?
From what I perceive images are either cached in RAM or they are not cached at all, regardless of this setting being enabled or disabled. Or at least it makes no perceivable performance difference here. So whatever this disk cache is supposed to do, I am not able to discern a difference (SSD) once RAM cache is full.
If it's bugged and fixed than it may make sense to keep the disk cache usable over multiple sessions as an option (over Editor restart).
From what I perceive images are either cached in RAM or they are not cached at all, regardless of this setting being enabled or disabled. Or at least it makes no perceivable performance difference here. So whatever this disk cache is supposed to do, I am not able to discern a difference (SSD) once RAM cache is full.
If it's bugged and fixed than it may make sense to keep the disk cache usable over multiple sessions as an option (over Editor restart).
Re: Multi-threaded image rendering
Hi @all,
for completeness of information, a related thread (and feature request) can be found here:
Preload pages in PDF XChange Viewer
![Image](http://666kb.com/i/cl7n4ym4ddqjn3wqn.png)
(RAM and CPU usage for rendering a large document, click to enlarge)
Regards
David
for completeness of information, a related thread (and feature request) can be found here:
Preload pages in PDF XChange Viewer
![Image](http://666kb.com/i/cl7n4ym4ddqjn3wqn.png)
(RAM and CPU usage for rendering a large document, click to enlarge)
Regards
David
David.P
PDF-XChange Pro
PDF-XChange Pro
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Hi guys,
Here's what I heard back from the Dev. Team (excuse the screen-shot, I wanted to retain formatting for clarity, with minimal editing):
![Image](http://i.imgur.com/Vi8BBdM.png)
**Edit** The developer sent me a part two & 3 to forward on:
![Image](http://i.imgur.com/phQtZPO.png)
![Image](http://i.imgur.com/CtWU1Iw.png?1)
Thanks,
Here's what I heard back from the Dev. Team (excuse the screen-shot, I wanted to retain formatting for clarity, with minimal editing):
![Image](http://i.imgur.com/Vi8BBdM.png)
**Edit** The developer sent me a part two & 3 to forward on:
![Image](http://i.imgur.com/phQtZPO.png)
![Image](http://i.imgur.com/CtWU1Iw.png?1)
Thanks,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I would totally like multi-threaded image rendering as an option. Waiting several seconds for larges images to render while my CPU is mostly idle is less ideal than allowing more CPU and memory usage to happen in return for faster rendering. Some sort of logic to decode small images on one thread and medium to large images on multiple threads should help to keep load in check.
And why does every thread have to decode parts that were already decoded by other threads before? If part 1-3 are already decoded when thread 4 begins its work then it can make use of that information.
Here is how two threads could do it, which should already be an improvement over just using a single thread?!
1. Thread 1 decodes part 1
2. Thread 1 renders part 1 + thread 2 decodes part 2
3. Thread 1 decodes part 3 + thread 2 renders part 2
4. Thread 1 renders part 3 + thread 2 decodes part 4
More threads would need a more complex interweaving of which threads have to decode more than 1 part at a time.
Overall this would be less of a problem if Editor would pre-render several pages in both directions, because then I wouldn't have to wait those seconds when I flip a page.
So what does the disk cache do for image rendering and why do I not observe any difference whether it's enabled or disabled (SSD, 16 gb RAM)? Should the disk cache not hold the decoded image information over different sessions and thus enable Editor to render those already decoded image parts multi-threaded? Of course this can eat away drive space quickly, but it's not as if all those web caches and GPU shader caches don't do the same anyway.
And why does every thread have to decode parts that were already decoded by other threads before? If part 1-3 are already decoded when thread 4 begins its work then it can make use of that information.
Here is how two threads could do it, which should already be an improvement over just using a single thread?!
1. Thread 1 decodes part 1
2. Thread 1 renders part 1 + thread 2 decodes part 2
3. Thread 1 decodes part 3 + thread 2 renders part 2
4. Thread 1 renders part 3 + thread 2 decodes part 4
More threads would need a more complex interweaving of which threads have to decode more than 1 part at a time.
Overall this would be less of a problem if Editor would pre-render several pages in both directions, because then I wouldn't have to wait those seconds when I flip a page.
So what does the disk cache do for image rendering and why do I not observe any difference whether it's enabled or disabled (SSD, 16 gb RAM)? Should the disk cache not hold the decoded image information over different sessions and thus enable Editor to render those already decoded image parts multi-threaded? Of course this can eat away drive space quickly, but it's not as if all those web caches and GPU shader caches don't do the same anyway.
Last edited by Timur Born on Wed Jul 26, 2017 3:20 pm, edited 1 time in total.
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Hi Timur,
I've just edited and posted a second & third piece that was sent to me by that same developer - please take a look at that too.
Thanks,
I've just edited and posted a second & third piece that was sent to me by that same developer - please take a look at that too.
Thanks,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Thanks for the additional information. This convinces me even more that we should be able to switch between rendering mode or maybe Editor should switch automatically based on the context, aka screen resolution and image complexity. DIN A0 sized CAD drawings with JPG backgrounds are regulars around here.
Lately I got me some PDF files with A3 sized JPG images/maps over several pages (one or more maps per page) where I felt the slow-down most. Even my usual letter/A4 sizes PDF books often come both with page filling background images (hopefully only decoded once if every page is the same) and images that fill between 1/10 to a full page. Any image between 1/4 to 1/2 page size really seems to slow down page rendering and especially page flipping noticeably.
Lately I got me some PDF files with A3 sized JPG images/maps over several pages (one or more maps per page) where I felt the slow-down most. Even my usual letter/A4 sizes PDF books often come both with page filling background images (hopefully only decoded once if every page is the same) and images that fill between 1/10 to a full page. Any image between 1/4 to 1/2 page size really seems to slow down page rendering and especially page flipping noticeably.
Re: Multi-threaded image rendering
Hi @all
I think that this is key:
Rendering different pages ahead and thereby assigning different threads to different pages should also be easier than rendering one page with multiple threads.
Therefore, my suggestion would be to start by implementing pre-rendering like discussed here. This already would make a major difference regarding the perceived speed of PDF-XChange Editor.
This also seems to be in line with what the Dev. Team just wrote in part 3 above.
Best Regards
David.P
I think that this is key:
If several pages in both directions would be pre-rendered, page flipping could be instantaneous in most cases, and it would not matter so much whether each of the pages is rendered in one or in multiple threads.Timur Born wrote:Overall this would be less of a problem if Editor would pre-render
Rendering different pages ahead and thereby assigning different threads to different pages should also be easier than rendering one page with multiple threads.
Therefore, my suggestion would be to start by implementing pre-rendering like discussed here. This already would make a major difference regarding the perceived speed of PDF-XChange Editor.
This also seems to be in line with what the Dev. Team just wrote in part 3 above.
Best Regards
David.P
David.P
PDF-XChange Pro
PDF-XChange Pro
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
For clarification: What takes longer, decoding or rendering?
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I agree with David (and the dev team) concerning pre-rendering. Thumbnails demonstrate that parallel decoding/rendering of multiple pages makes a big difference. Adobe Reader does pre-rendering and for sequential reading this is great. Reader is still slower to flip pages quickly, though.
PS: I also just discovered a bug with thumbnail rendering when 16 threads are used for that (auto or manual):
When Editor is started fresh then only the first 16 thumbnails are rendered in parallel. The rest of the current thumbnail window is rendered one by one sequentially (1 core). Editor switches back to 16 threads only once all thumbnails of the pane are finished, the scroll-bar is moved for the first time, the pane size is changed considerably (not just a bit) or the zoom factor is changed.
Just saw that happen when I switched to a different tab, so it does not only happen after a fresh start.
PS: I also just discovered a bug with thumbnail rendering when 16 threads are used for that (auto or manual):
When Editor is started fresh then only the first 16 thumbnails are rendered in parallel. The rest of the current thumbnail window is rendered one by one sequentially (1 core). Editor switches back to 16 threads only once all thumbnails of the pane are finished, the scroll-bar is moved for the first time, the pane size is changed considerably (not just a bit) or the zoom factor is changed.
Just saw that happen when I switched to a different tab, so it does not only happen after a fresh start.
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Hi guys,
Regarding pre-rendering - we are already planning to add this, but it's a medium - long term implementation.
Cheers,
It depends on various factors. Decoding is relatively constant, but the rendering will vary.For clarification: What takes longer, decoding or rendering?
Regarding pre-rendering - we are already planning to add this, but it's a medium - long term implementation.
I'll pass that along to the devs to comment.PS: I also just discovered a bug with thumbnail rendering when 16 threads are used for that (auto or manual):
When Editor is started fresh then only the first 16 thumbnails are rendered in parallel. The rest of the current thumbnail window is rendered one by one sequentially (1 core). Editor switches back to 16 threads only once all thumbnails of the pane are finished, the scroll-bar is moved for the first time, the pane size is changed considerably (not just a bit) or the zoom factor is changed.
Cheers,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Hi Timur,
We've tried reproducing this here but none of us are able. We've also tried using the file that you sent previously, but that doesn't appear to display the problem. Is there a different file that you're seeing this with, or are you seeing this with that same file?
Cheers,
We've tried reproducing this here but none of us are able. We've also tried using the file that you sent previously, but that doesn't appear to display the problem. Is there a different file that you're seeing this with, or are you seeing this with that same file?
Cheers,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
The file I sent you is too small to check this properly, I used files of several hundreds pages size. Right after Editor start it also happens when the thumbnail panel starts small and then is pulled bigger, the newly visible thumbnails then are decoded/rendered one by one. Scrolling just one line of thumbnails may not solve this immediately, but scrolling in the main document does.
I also found bugs with the ram and disc cache, but will open a new thread for these.
I also found bugs with the ram and disc cache, but will open a new thread for these.
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Ah okay - thanks for the clarification. I have a few docs that may help test, or can probably put something together. Judging by what I've seen of your previous files, I'm assuming that these docs are fairly image heavy?
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Cheers,
Perfect, thanksI also found bugs with the ram and disc cache, but will open a new thread for these.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Cheers,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Indeed they are. And my 30" screen allows several dozen thumbnails to be displayed at once, so reproducing this bug is easy here.
Let me underline again that the first 16 thumbnails (8 core / 16 thread CPU) are rendered concurrently, only then Editor begins to render/decode them one by one. That's why small documents do little to reproduce this, i.e. that "Players Guide" document you have is only 12 pages in total.
![Wink ;)](./images/smilies/icon_wink.gif)
- Will - Tracker Supp
- Site Admin
- Posts: 6815
- Joined: Mon Oct 15, 2012 9:21 pm
- Location: London, UK
- Contact:
Re: Multi-threaded image rendering
Thanks Timur, we'll try to keep you posted ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Thank you.
Best regards
Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I am still trying to find out where the bottle-necks in Editor's PDF rendering are. One thing I noticed is that while I experience lags during Editor's memory cache buildup none of my CPU cores is fully utilized.
For better comparison I measured two performance settings, one where Editor is set to only use 1 thread and one where Editor is set to use 8 threads (max). The result can be seen in the following screenshots. Most of the time the used cores are not maxed out, on average single core load is below 70%.
1 thread 8 threads I checked SSD load, but that doesn't seem to be a culprit. So where is the bottle-neck?
For better comparison I measured two performance settings, one where Editor is set to only use 1 thread and one where Editor is set to use 8 threads (max). The result can be seen in the following screenshots. Most of the time the used cores are not maxed out, on average single core load is below 70%.
1 thread 8 threads I checked SSD load, but that doesn't seem to be a culprit. So where is the bottle-neck?
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
To clarify the "average" reading: This was measured during load while Editor was flipping (not scrolling) through hundreds of pages with a Logitech hyper-fast scrolling wheel spinning freely. By the means of an Autohotkey script the scroll command kept going to the Editor window regardless of mouse-pointer position or focus. So Editor was kept busy rendering new pages with little to no idle time.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
On a side note: most of the renderings threads can be suspended without Editor being (noticeably) affected. But the other rendering threads increase their CPU load to a permanent 70-100% as soon as the first new line is rendered then and stay there even when Editor is idle in the background. So some active polling (waiting?) seems to happen between the rendering threads, even though the rendering still works without the suspended thread(s)?!
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
This is how Editor scales with 8 and 16 threads flipping pages in Two Pages view. The document uses the very same background and logo images on every double-page, with occasional additional images thrown in on some pages. Flipping pages noticeably lags as long as those pages are not cached in memory yet.
Here is an example page. Even downsized one can clearly see that the page consists only of text on top of the background image, plus a logo in the upper left corner. Most of the pages look like this, with no variation in the images. Those pages that feature additional images usually lag more when flipping pages, aka need more time for being built up. The latter depends on the size of the image, with full page images taking the longest, more threads don't help then.
As can be seen most threads remain unused by Editor (<0.01% CPU load) most of the time. And even with the additional threads/cores being used I can hardly make out a lag difference - if any - between using 2 maximum threads or 16. So whatever causes these lags of uncached pages, throwing more cores at it doesn't seem to help.
16 threads setting
8 threads setting
On a side note: Setting Editor to only use 1 rendering thread still uses 2 threads on top of the main process thread. It seems to do exactly the same as setting 2 rendering threads.
Here is an example page. Even downsized one can clearly see that the page consists only of text on top of the background image, plus a logo in the upper left corner. Most of the pages look like this, with no variation in the images. Those pages that feature additional images usually lag more when flipping pages, aka need more time for being built up. The latter depends on the size of the image, with full page images taking the longest, more threads don't help then.
As can be seen most threads remain unused by Editor (<0.01% CPU load) most of the time. And even with the additional threads/cores being used I can hardly make out a lag difference - if any - between using 2 maximum threads or 16. So whatever causes these lags of uncached pages, throwing more cores at it doesn't seem to help.
16 threads setting
8 threads setting
On a side note: Setting Editor to only use 1 rendering thread still uses 2 threads on top of the main process thread. It seems to do exactly the same as setting 2 rendering threads.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I used the Content panel to select all images and remove them. What remains is text and lots of path objects. Those path objects make a good part of the page border art even when the background images are removed. Seems like Editor needs to re-render those path objects on every page, even when they do not change visually. The lag for flipping to uncached pages remained, so image decoding does not seem to be the (sole) culprit.
Next I removed all "Shapes" from the document, aka all those "Path" objects. And voila, not only does this reduce the lag, but it also leads to Editor finally utilizing all threads. That being said, page rendering still takes longer than viewing the same page from memory cache, even though the CPU cores are not even half utilized. So there are still bottle-necks left in pure text rendering.
Removing only "Shapes" with leaving images intact, or removing only images with leaving shapes intact also results in all threads being used, but the lag is noticeably worse than just rendering text. I find this rather strange, because on most pages the very same images and shapes are used over and over again in the same locations. I would expect Editor being able to only decode and render these images once and then use them from memory cache even on new pages?!
While working on all of this I noticed that the selection and deletion of content runs on a single (!) thread only. Editor left me waiting for the results accordingly, especially for the deletion of the many many shapes.
Next I removed all "Shapes" from the document, aka all those "Path" objects. And voila, not only does this reduce the lag, but it also leads to Editor finally utilizing all threads. That being said, page rendering still takes longer than viewing the same page from memory cache, even though the CPU cores are not even half utilized. So there are still bottle-necks left in pure text rendering.
Removing only "Shapes" with leaving images intact, or removing only images with leaving shapes intact also results in all threads being used, but the lag is noticeably worse than just rendering text. I find this rather strange, because on most pages the very same images and shapes are used over and over again in the same locations. I would expect Editor being able to only decode and render these images once and then use them from memory cache even on new pages?!
While working on all of this I noticed that the selection and deletion of content runs on a single (!) thread only. Editor left me waiting for the results accordingly, especially for the deletion of the many many shapes.
- John - Tracker Supp
- Site Admin
- Posts: 5219
- Joined: Tue Jun 29, 2004 10:34 am
- Location: United Kingdom
- Contact:
Re: Multi-threaded image rendering
Hi,
respectfully Timur - our DEV's and Support team don't have the time to discuss in detail every developer's ideas on how and why everything works the way it does - do you have a specific question - for example, are you hoping to remove all content and images from these pages and be left just with the text or its properties?
I appreciate that when trying to trace a bug or fault in the software - detail can be very helpful - but in this case it would appear you simply wish to do the above - if not please advise what you specifically wish to achieve as concisely as possible and we will endeavour to answer in the same manner.
Thank you.
respectfully Timur - our DEV's and Support team don't have the time to discuss in detail every developer's ideas on how and why everything works the way it does - do you have a specific question - for example, are you hoping to remove all content and images from these pages and be left just with the text or its properties?
I appreciate that when trying to trace a bug or fault in the software - detail can be very helpful - but in this case it would appear you simply wish to do the above - if not please advise what you specifically wish to achieve as concisely as possible and we will endeavour to answer in the same manner.
Thank you.
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.
Best regards
Tracker Support
http://www.tracker-software.com
Best regards
Tracker Support
http://www.tracker-software.com
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
What I wish is better CPU scaling so that page rendering takes less time (less lag) on modern CPU hardware. We get more and more CPU cores, but reading PDF files still is a "waiting" experience.
I am hoping for multiple CPU cores to be more useful for rendering and other work tasks (like selection, deletion and undo). And for content - especially images - that appears on nearly every page I wish it to be only decoded/pre-rendered once and than reused from cache when it appears on consecutive pages.
So consider this a feature/improvement request, underpinned by measurement numbers that are meant to bolster my point.
I am hoping for multiple CPU cores to be more useful for rendering and other work tasks (like selection, deletion and undo). And for content - especially images - that appears on nearly every page I wish it to be only decoded/pre-rendered once and than reused from cache when it appears on consecutive pages.
So consider this a feature/improvement request, underpinned by measurement numbers that are meant to bolster my point.
Last edited by Timur Born on Wed Sep 06, 2017 1:02 pm, edited 1 time in total.
- Tracker Supp-Stefan
- Site Admin
- Posts: 17948
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact:
Re: Multi-threaded image rendering
Hello Timur,
We've just had a discussion with the devs - and unfortunately there is little room for improvement, as the PDF page content needs to be decoded and rendered sequentially.
We will see what can be done so that we can utilize more than one thread (e.g. one will render an already decoded image while another thread continues the decoding process) - but there are limitations in the PDF standard itself that can prevent us from making some significant changes. I've created a ticket in our internal system - and here is it's number:
#4021: FR: Multi-threaded page rendering for better CPU utilization
As for the caching - it is already happening - and if you keep at the same zoom level - content is cached and reused. There was a separate thread about the caching if I remember correctly, and there my colleagues tried to explain to you why the current caching is working in the way it is, and that making changes to the caching process will not bring any noticeable improvements.
Regards,
Stefan
We've just had a discussion with the devs - and unfortunately there is little room for improvement, as the PDF page content needs to be decoded and rendered sequentially.
We will see what can be done so that we can utilize more than one thread (e.g. one will render an already decoded image while another thread continues the decoding process) - but there are limitations in the PDF standard itself that can prevent us from making some significant changes. I've created a ticket in our internal system - and here is it's number:
#4021: FR: Multi-threaded page rendering for better CPU utilization
As for the caching - it is already happening - and if you keep at the same zoom level - content is cached and reused. There was a separate thread about the caching if I remember correctly, and there my colleagues tried to explain to you why the current caching is working in the way it is, and that making changes to the caching process will not bring any noticeable improvements.
Regards,
Stefan
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Hi Stefan,
thanks for the reply!
Seeing how editing functions like selection, deletion and undo (equivalent to insert?) are done on only a single thread I would expect some room for improvements there, too.
PS: Having two rendering threads when only one is set in preferences only seems to happen max threads is decreased to 1 without restarting Editor.
thanks for the reply!
Two Pages view takes longer than One Page view even while CPU resources are free, so there is one place where improvements for synchronous mode may be possible. This is even true for pure text pages that have all their images and shapes removed.Tracker Supp-Stefan wrote:We will see what can be done so that we can utilize more than one thread (e.g. one will render an already decoded image while another thread continues the decoding process) - but there are limitations in the PDF standard itself that can prevent us from making some significant changes.
Seeing how editing functions like selection, deletion and undo (equivalent to insert?) are done on only a single thread I would expect some room for improvements there, too.
I can say so much. My test document uses the very same background images + logo (and shapes) on hundreds of pages. In theory it only needs to be decoded and rendered once and then text needs to be put on top of it. Nevertheless it takes longer to display pages using those recurring images than rendering the same pages with said images removed. So do recurring images (and shapes) get cached for use of previously unrendered pages or does the cache only handle fully (pre)rendered pages and thus has the CPU re-render the same objects over and over again on every new page?As for the caching - it is already happening - and if you keep at the same zoom level - content is cached and reused.
Yes, these performance related points overlap each other and I do not fully agree with the arguments being made. Even the rendering of pure text is still noticeable on a 8C/16T Ryzen 1800X at 3.95 GHz (+3333-C14 RAM). So the only thing left to do is to switch to a i7/9 CPU and overclock towards 5 GHz and keep watching the remaining lag?! I still hope that software can come up with better solutions.There was a separate thread about the caching if I remember correctly, and there my colleagues tried to explain to you why the current caching is working in the way it is, and that making changes to the caching process will not bring any noticeable improvements.
PS: Having two rendering threads when only one is set in preferences only seems to happen max threads is decreased to 1 without restarting Editor.
- Tracker Supp-Stefan
- Site Admin
- Posts: 17948
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact:
Re: Multi-threaded image rendering
Thanks for the feedback Timur,
Yes - two page view might indeed be a good area for improvement!
The suggestion you made for the images might not work though - even if the same image repeats on every page. The pages inside a PDF file are independent objects - just as actual sheets of paper can be separated (it's not so easy to split a Word document for instance as the text there flows through the whole file). Even if the repeating image is stored once in the bytes of the file - each page will read and request it on it's own - and the page itself has to be rendered as a whole and can't be 'built up' from the already rendered image for the previous page + other elements.
There might be other performance improvements that can be made - but cache wise - it is going to be an overkill if we try to redesign things. Also the improvements will be in the range of a few %, so we really do not believe it worth digging in that direction. Yes your machine might have lots of computing power available and we will try to utilize some of that with the improvements discussed above, but caching is best left at it's current stable and working state.
Regards,
Stefan
Yes - two page view might indeed be a good area for improvement!
The suggestion you made for the images might not work though - even if the same image repeats on every page. The pages inside a PDF file are independent objects - just as actual sheets of paper can be separated (it's not so easy to split a Word document for instance as the text there flows through the whole file). Even if the repeating image is stored once in the bytes of the file - each page will read and request it on it's own - and the page itself has to be rendered as a whole and can't be 'built up' from the already rendered image for the previous page + other elements.
There might be other performance improvements that can be made - but cache wise - it is going to be an overkill if we try to redesign things. Also the improvements will be in the range of a few %, so we really do not believe it worth digging in that direction. Yes your machine might have lots of computing power available and we will try to utilize some of that with the improvements discussed above, but caching is best left at it's current stable and working state.
Regards,
Stefan
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
That's fine, especially because I mean to discuss multi-core improvements here. ![Wink ;)](./images/smilies/icon_wink.gif)
It's just a shame that modern software still leaves most of the CPUs processing power barren while the user has to wait for results to appear on screen. Maybe it's time to replace PDF with a more modern format then.
Could Editor's own functions be made multi-threaded, though?! Like the deletion of all shapes or images that currently only runs on a single thread?
![Wink ;)](./images/smilies/icon_wink.gif)
It's just a shame that modern software still leaves most of the CPUs processing power barren while the user has to wait for results to appear on screen. Maybe it's time to replace PDF with a more modern format then.
Could Editor's own functions be made multi-threaded, though?! Like the deletion of all shapes or images that currently only runs on a single thread?
- Lzcat - Tracker Supp
- Site Admin
- Posts: 677
- Joined: Thu Jun 28, 2007 8:42 am
Re: Multi-threaded image rendering
Hi Timur.Timur Born wrote:Could Editor's own functions be made multi-threaded, though?! Like the deletion of all shapes or images that currently only runs on a single thread?
In most cases data modification must be done in one thread to keep data integrity. In some cases data can be split into parts which can be processed in separate threads, but in most cases this is require a lot of additional coding:
1. Split data to parts (1 thread)
2. Run threads with their tasks (may be many threads, but count depends of parts count). And because most data parts with use same shared data worker threads may wait until another thread will release shared data (so in worst case performance may be even lower than using one thread).
3. Merge modified data (1 thread, require to wait for all tasks completion).
So things are not so easy as you may suppose. Of course we will try to optimize what we can, but there is a lot other things to do, and many of them are more important then possible performance improvements in some cases, so you should be patient and wait. Or you may try to write your own superfast application
![Smile :)](./images/smilies/icon_smile.gif)
Victor
Tracker Software
Project manager
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Tracker Software
Project manager
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Is Editor supposed to allocated threads to the same "Ideal Core" when others are still unused?
Here are two example "Ideal Core" allocations with rendering threads set to 8 and working threads set to 16. Core Parking disabled, running on a 8C/16T CPU.
Actively rendering: 2, 3, 6, 7, 10, 11, 15, 15
PdfXEdit.exe: 14
Actively rendering: 3, 6, 7, 10, 11, 11, 14, 15
PdfXEdit.exe: 14
As you can see there are instances where rendering threads seem to be allocated to the same core, even though other cores (working threads) are mostly idle (<0.01%). Ideally those actively rendering threads should not share cores while other cores are still free. When two threads share a core and thus run slower, don't they make other threads wait for their calculations to finish?
And there are instances where rendering is allocated to a core that already is busy handling the PdfXEdit.exe main thread. The latter is especially problematic when the number of rendering threads is equal to the number of working threads (like 16/16). It might be helpful to limit the number of rendering threads to working threads -1 (like 15/16), so that the .exe can have its own core without having two rendering threads share a single core just to leave a core to the .exe thread.
Here are two example "Ideal Core" allocations with rendering threads set to 8 and working threads set to 16. Core Parking disabled, running on a 8C/16T CPU.
Actively rendering: 2, 3, 6, 7, 10, 11, 15, 15
PdfXEdit.exe: 14
Actively rendering: 3, 6, 7, 10, 11, 11, 14, 15
PdfXEdit.exe: 14
As you can see there are instances where rendering threads seem to be allocated to the same core, even though other cores (working threads) are mostly idle (<0.01%). Ideally those actively rendering threads should not share cores while other cores are still free. When two threads share a core and thus run slower, don't they make other threads wait for their calculations to finish?
And there are instances where rendering is allocated to a core that already is busy handling the PdfXEdit.exe main thread. The latter is especially problematic when the number of rendering threads is equal to the number of working threads (like 16/16). It might be helpful to limit the number of rendering threads to working threads -1 (like 15/16), so that the .exe can have its own core without having two rendering threads share a single core just to leave a core to the .exe thread.
- Lzcat - Tracker Supp
- Site Admin
- Posts: 677
- Joined: Thu Jun 28, 2007 8:42 am
Re: Multi-threaded image rendering
Hi Timur.
Which books have you read about multithreading? Do you know how multithreading in windows works? If not - please read some technical documentation or books (for example this).
We do not set threads or process affinity (as in most cases this does not give significant performance boost and may result performance degradation), so OS manage them.
Which books have you read about multithreading? Do you know how multithreading in windows works? If not - please read some technical documentation or books (for example this).
We do not set threads or process affinity (as in most cases this does not give significant performance boost and may result performance degradation), so OS manage them.
Victor
Tracker Software
Project manager
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
Tracker Software
Project manager
Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Hi Victor.Lzcat - Tracker Supp wrote:Hi Timur.
None, but I am open to suggestions, especially regarding any documentation that does not just list API formats for coders.Which books have you read about multithreading?
Thanks for the link, but indeed I know most of the things described in there already. Even more important, I know them not only in theory, but also in practice. That is because part of my business is analyzing threading and priority behavior of professional audio drivers, digital audio workstation software (DAW), BIOS, hardware and OS behavior. For example, I just identified and analyzed a serious processor scheduler issue regarding threads and priorities that leads to ongoing GUI stalls - input and output and even some processing - in W10 "Creators" (vs. Anniversary).Do you know how multithreading in windows works? If not - please read some technical documentation or books (for example this).
I will still give the linked article another read and do not claim to know the intricacies of coding all this stuff. This is why I present you with measured results in order for you to come to your own educated conclusions.
And this is where I see a possible culprit. But let me quote from the linked Mark E. Russinovich and David A. Solomon article first and highlight some lines:We do not set threads or process affinity (as in most cases this does not give significant performance boost and may result performance degradation), so OS manage them.
Now let's get back to what I actually measured when running Editor using 8 rendering threads on my 8C/16T CPU. For more clarity I reformat my last measurement:Mark E. Russinovich and David A. Solomon wrote:The ideal processor for a thread is chosen when a thread is created using a seed in the process block. The seed is incremented each time a thread is created so that the ideal processor for each new thread in the process will rotate through the available processors on the system.
...
Note that this assumes the threads within a process are doing an equal amount of work. This is typically not the case in a multithreaded process, which normally has one or more housekeeping threads and then a number of worker threads. Therefore, a multithreaded application that wants to take full advantage of the platform might find it advantageous to specify the ideal processor numbers for its threads by using the SetThreadIdealProcessor function.
...
On hyperthreaded systems, the next ideal processor is the first logical processor on the next physical processor.
Actively rendering (as in actual CPU load happening) "Ideal Processor" cores, sorted by physical cores (AMD 1800X), measured via Process Explorer:
Core 1 (CCX1): 3
Core 4 (CCX2): 6, 7
Core 5 (CCX2): 10, 11, 11,
Core 7 (CCX2): 14, 15
PdfXEdit.exe: Core 7: 14
- Out of 8 physical cores only 4 were used by Editor, out of 16 logical cores only 7 were used by Editor. The other cores remained mostly idle and unused on my system.
- Only 1 out of 9 threads were allocated to a single physical core.
- 6 out of 9 threads were allocated to only two physical cores, with 3 threads sharing a single physical core (Hyperthreading/SMT).
- 4 out of 9 threads even shared the same (Hyperthreading/SMT) logical core with another thread (11+11 and 14+14) while the other logical core of the same physical core was also utilized.
This was with the number of rendering threads being set to 8 and number of working threads being set to 16. If Windows just brainlessly "rotates through the available processors" then giving it a hint in form of "Ideal Processor" affinity seems like a good idea and exactly what the function "SetThreadIdealProcessor(Ex)" was implemented for?! I understand it as a "suggestion" to the Windows processors scheduler to help it make better educated decisions.
It seems that my expensive hardware is not put to good use by Editor's current multi-threading implementation, as some cores (even Hyperthreading) seem over-utilized while others remain idle. This is why I feel that Editor could maybe be improved in these areas.Windows Dev Center wrote:Sets a preferred processor for a thread. The system schedules threads on their preferred processors whenever possible.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
One more thing to add here: Even when I set only 4 threads maximum for rendering, thumbnails and working it happens regularly that the PdfXEdit.exe thread shares a logical core with one of the rendering threads. Overall it seems to happen most of the time at any number of threads higher than 2 (or when a higher number is decreased to 2 without restarting Editor).
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I also wonder why there are always two PDFXEditCore.x64.dll threads present that occupy CPU cores without ever doing any processing (zero CPU cycles)?! There is also one thread that never exceeds 0.01% CPU load ever.
All three of these threads seem to be created before the load intensive rendering threads and thus occupy physical CPU cores for no good use. All the while making (dumb) Windows cramp the rendering threads onto whatever cores are left, aka allocating the most important threads to already busy cores in a somewhat random fashion. Please consider making use of Windows' "Ideal Core" concept to better allocate rendering threads to free physical cores, Editor knows best which threads are processing heavy and which are not.
I also noticed that there is a DropboxExt64.18.0.dll thread present, even though I disabled the Dropbox plugin.
All three of these threads seem to be created before the load intensive rendering threads and thus occupy physical CPU cores for no good use. All the while making (dumb) Windows cramp the rendering threads onto whatever cores are left, aka allocating the most important threads to already busy cores in a somewhat random fashion. Please consider making use of Windows' "Ideal Core" concept to better allocate rendering threads to free physical cores, Editor knows best which threads are processing heavy and which are not.
I also noticed that there is a DropboxExt64.18.0.dll thread present, even though I disabled the Dropbox plugin.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
I just noticed one more area where Editor is purely single-threaded: Search of multiple documents.
At least I would assume that searching 8 documents in parallel using 8 threads may lead to faster results than searching one document after another using only a single thread?!
At least I would assume that searching 8 documents in parallel using 8 threads may lead to faster results than searching one document after another using only a single thread?!
- Tracker Supp-Stefan
- Site Admin
- Posts: 17948
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact:
Re: Multi-threaded image rendering
Hi Timur,
Thanks for bringing this up.
I have passed that along, and as soon as we start looking at ways to improve multi threaded usage - we will have the search into consideration as well!
Regards,
Stefan
Thanks for bringing this up.
I have passed that along, and as soon as we start looking at ways to improve multi threaded usage - we will have the search into consideration as well!
Regards,
Stefan
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
As a last remark about multi-threading in Editor:
Total CPU load is always the same for scrolling in a complex document (columns of text, tables, bitmap images and shapes), regardless of how many threads are used.
I get 10% total load for Editor using 2 threads and I get 10% total load using 16 threads. The higher the number of threads the lower the load on each thread, so total load is just divided by threads without any performance improvement being noticeable. Using synchronous mode that is.
Total CPU load is always the same for scrolling in a complex document (columns of text, tables, bitmap images and shapes), regardless of how many threads are used.
I get 10% total load for Editor using 2 threads and I get 10% total load using 16 threads. The higher the number of threads the lower the load on each thread, so total load is just divided by threads without any performance improvement being noticeable. Using synchronous mode that is.
- Tracker Supp-Stefan
- Site Admin
- Posts: 17948
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact:
Re: Multi-threaded image rendering
Hi Timur,
I have an older CPU with just 4 cores and 4 threads, but am noticing a different result than you.
With Synchronous mode set to Off - I could only get about 50% CPU usage. With Synchronous on - I could get almost 100% usage, and the third image is with the initial rendering, and then scrolling quickly through the same file again. Apparently for the initial rendering all 4 of my cores are used, and later when scrolling through the already rendered content - just one of them.
I made sure to close as many of the side processes as possible to make sure that the CPU is free to be loaded by the Editor.
Regards,
Stefan
I have an older CPU with just 4 cores and 4 threads, but am noticing a different result than you.
With Synchronous mode set to Off - I could only get about 50% CPU usage. With Synchronous on - I could get almost 100% usage, and the third image is with the initial rendering, and then scrolling quickly through the same file again. Apparently for the initial rendering all 4 of my cores are used, and later when scrolling through the already rendered content - just one of them.
I made sure to close as many of the side processes as possible to make sure that the CPU is free to be loaded by the Editor.
Regards,
Stefan
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
2 rendering, 16 thumbnail, 16 working:
16 rendering, 16 thumbnail, 16 working:
No perceived or measurable performance difference while scrolling through uncached pages of the PDF file.
16 rendering, 16 thumbnail, 16 working:
No perceived or measurable performance difference while scrolling through uncached pages of the PDF file.
-
- User
- Posts: 874
- Joined: Tue Jun 26, 2012 1:50 pm
Re: Multi-threaded image rendering
Once all shapes and images are removed the remaining text rendering runs effectively at single-core load (6.25%). Splitting it into more threads again results in the same total CPU load and no perceivable performance differences. This is even worse than before, because with shapes and images present there at least is a difference between using 1 thread and 2-16 threads in Two Pages View.
Another curious observation: When Editor flushes its memory cache the whole process is stalled for several seconds while only a single thread is maxed out.
Another curious observation: When Editor flushes its memory cache the whole process is stalled for several seconds while only a single thread is maxed out.
- Tracker Supp-Stefan
- Site Admin
- Posts: 17948
- Joined: Mon Jan 12, 2009 8:07 am
- Location: London
- Contact:
Re: Multi-threaded image rendering
Hi Timur,
Thanks for the feedback - this is getting a bit beyound my expertise to comment on further so I will have the devs working on multi-threading have a read through this whole topic once again, and have all points outlined in mind when working on improving our CPU utilization.
Regards,
Stefan
Thanks for the feedback - this is getting a bit beyound my expertise to comment on further so I will have the devs working on multi-threading have a read through this whole topic once again, and have all points outlined in mind when working on improving our CPU utilization.
Regards,
Stefan