A method of pdf page rendering cache

Abstract

The application discloses a PDF page rendering cache method, which comprises the following steps: S1, uniformly dividing a whole PDF page into multiple fixed blocks; S2, performing first rendering on a to-be-displayed part when the page is first loaded, and adding a rendering result in a fixed block to a cache list of the fixed block if a width of a rendering result area intersecting any fixed block is equal to a width of the corresponding fixed block; S3, when the page needs to be rendered again, checking a cache list stored in each fixed block, and performing rendering on a region outside an intersecting region if the intersecting region has been cached, and splicing the rendering region and the intersecting region to output a current rendering result; S4, if a width of a rendering region intersecting any fixed block is equal to a width of the corresponding fixed block in S3, adding the rendering result in the fixed block to the cache list of the fixed block; and S5, repeating S3 and S4 until the rendering is completed.

Description

Technical Field

[0001] This invention relates to the field of PDF page rendering caching technology, and more specifically, to a method for PDF page rendering caching. Background Technology

[0002] In many high-level applications, rendering of documents such as design drawings and engineering drawings is slow. Re-rendering areas that have already been rendered requires re-rendering, resulting in repeated time consumption. For example, when browsing a PDF page, if the displayed content is larger than the window's display area, scrolling is required to view the PDF content. In this case, the PDF browsing application needs to call the `render` function to re-render the portion of the PDF object in the window. For some files, the PDF object is complex, and rendering complex PDF objects takes considerable time, resulting in choppy and laggy display when browsing PDF pages.

[0003] Adobe Acrobat (a PDF (Portable Document Format) editing software developed by Adobe) also exhibits slow initial rendering. Therefore, it caches the rendered areas to improve the speed when displaying the same area again. However, excessive caching can also affect the efficiency of subsequent rendering. How to cache the rendering of PDF pages to improve the refresh efficiency and reduce lag when browsing PDF pages is a problem that those skilled in the art wish to solve. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a method for PDF page rendering caching. By evaluating whether the rendered PDF page results need to be cached, if the corresponding area's image is cached, the cached image can be automatically stitched together during subsequent screen refreshes, thereby significantly improving the screen refresh speed when the rendered content is displayed again.

[0005] To achieve the above objectives, the present invention provides a method for PDF page rendering caching, comprising:

[0006] Step S1: Divide the entire PDF page evenly into multiple fixed blocks;

[0007] Step S2: When the page is loaded for the first time, the part to be displayed is rendered for the first time, and the rendered result area is compared with each fixed block that can intersect. If the width of the intersection between the rendered result area and any fixed block is equal to the width of the corresponding fixed block, the rendering result in this fixed block is added to the cache list of this fixed block.

[0008] Step S3: When the page needs to be rendered again, iterate through and check the cache list stored in each fixed block. If the area to be rendered intersects with the already cached area, call the render function to render the area outside the intersection area, and concatenate the area to be rendered this time with the intersection area to output the rendering result.

[0009] Step S4: Check the region rendered in step S3 and each fixed block that can intersect. If the width of the intersection between the region rendered in step S3 and any fixed block is equal to the width of the corresponding fixed block, then add the rendering result in this fixed block to the cache list of that fixed block.

[0010] Step S5: Repeat steps S3 and S4 until rendering is complete.

[0011] In one embodiment of the present invention, step S2, which involves splicing the rendered region with the intersecting region, specifically employs the bitmap Transform method.

[0012] In one embodiment of the present invention, the update logic of the cache list is specifically as follows:

[0013] Use "resolution + rotation angle" in all cached rendered areas as the first dimension grouping identifier, and then use "rendering time" as the second dimension grouping identifier in a group of cached data with the same resolution and rotation angle.

[0014] Furthermore, a threshold is set in the cache pool. When the size of the overall data in the cache pool reaches the threshold or when a specified size of cache needs to be released in the application layer, the cache is released first based on the group identifier of the first dimension combined with the LRU principle. If the currently cached rendered areas are all of the same resolution and rotation angle, the rendered areas with shorter rendering times are released first based on the rendering time of each rendered area. The rendering time is the time taken for this area to start rendering and finish rendering.

[0015] In one embodiment of the present invention, the multiple fixed blocks are nine fixed blocks, distributed in a nine-square grid.

[0016] The PDF page rendering caching method provided by this invention, compared with the prior art, improves the rendering efficiency of PDF pages by determining the rendering area that needs to be cached for each fixed block when browsing PDF pages, thereby reducing the size of the page area that needs to be rendered subsequently. This reduces the occurrence of lag when browsing PDF pages. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figures 1A to 1C This is a schematic diagram of an initial scheme according to an embodiment of the present invention;

[0019] Figure 2 This is a schematic diagram of an improved embodiment of the present invention;

[0020] Figure 3 This is a flowchart of an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] Figures 1A to 1C This is a schematic diagram of an initial scheme according to an embodiment of the present invention, as shown below. Figures 1A to 1C This embodiment initially provides a method for PDF page rendering caching. Firstly, the cache area is not fixed. After each PDF page rendering, the rendering result on the client (device) is compared with the result in the cache, and multiple intersecting areas are identified. Non-intersecting areas are used as new rendering areas, while the remaining areas use the results already saved in the cache. The final display result to be rendered is then pieced together using the Bitmap's Transform method (a function that changes the final display result of the original resource image on the client). The newly rendered Bitmap also needs to be segmented and organized before being added to the cache list as a new cache object. The specific process includes the following:

[0023] S1: Perform the first rendering of the PDF page when the cache is empty. Since the cache is empty before the first rendering, the rendering result only needs to be added to the cache by region. Figure 1A The first rendered region A is added to the cache;

[0024] S2: After scrolling the page, a second rendering is performed. Since the cache already contains area A from the first rendering, the area to be rendered the second time is different from the area rendered the first time. The area to be rendered the second time is... Figure 1B Region B in the text, such as Figure 1B As shown, the first rendered region A intersects with the second rendered region B, which is region 3 in the figure. Therefore, when performing the second rendering, it is necessary to first find the intersection region (region 3) between the second rendered region (region B) and the first rendered region (region A), and retrieve the intersection region from the cache (this part does not need to be rendered again and can be read directly). The regions that do not intersect are rendered for the second time (regions 1 and 2). Then, the result of this rendering is combined with the retrieved intersection region to form the result of the second rendering, which is the entire region B.

[0025] S3: Reorganize and divide the areas to be rendered for the second time (areas 1 and 2) into regular rectangular parts (areas 1 and 2), and add each of the divided rectangular parts as an element to the cache list;

[0026] S4: After the page scrolls, a third rendering is performed. At this point, the cache already contains area A from the first rendering and areas 1 and 2 from area B from the second rendering. The area from the second rendering has been divided into two rectangular parts (areas 1 and 2) and stored in the cache list. The third rendering requires... Figure 1C Therefore, it is necessary to first find the intersection regions (regions 1, 2, and 3) between the entire region C and all cached regions (regions A and B) in the cache, then retrieve the intersection regions (regions 1, 2, and 3) from the cache respectively, and perform a third rendering on the non-intersecting parts of the entire region C. Finally, the rendering result is combined with the intersection regions (regions 1, 2, and 3) to form the third rendering result, which is the entire region C.

[0027] S5: After reorganizing the area rendered in the third rendering, it is divided into several rectangular parts (areas 4 and 5) and added to the cache list respectively.

[0028] S6: Repeat steps S4 to S5 after the page scrolls to continue rendering and caching the page.

[0029] Since the cache pool typically has a size limit, it may become full during the continuous rendering and caching of rendered areas. Therefore, the cache list needs to be updated. In this embodiment, the update logic for the cache list is as follows:

[0030] The first dimension grouping identifier is "resolution + rotation angle" in all cached rendered areas. Then, "rendering time" is used as the second dimension grouping identifier in a group of cached data with the same resolution and rotation angle. The "resolution + rotation angle" is mainly used to index cached images. For example, on the same page, displaying a cached image at 100% and displaying a cached image at 150% are different. The cached images displayed on pages with different rotation angles are also different.

[0031] Furthermore, a threshold is set in the cache pool. When the size of the overall data in the cache pool reaches the threshold or when the application layer sets the need to release a cache of a specified size, the cache is released first based on the grouping identifier of the first dimension, namely "resolution + rotation angle", combined with the LRU principle (Least Recently Used). If the currently cached rendered areas are all with the same resolution and rotation angle, the rendered areas with the shorter rendering time are released first based on the rendering time of each rendered area. The rendering time is the time taken for this area from the start of rendering to the completion of rendering.

[0032] In the aforementioned initial scheme, since the cache list is more suitable for storing rectangular areas to facilitate subsequent caching, when the area to be newly rendered is irregular, it is necessary to organize and divide the irregular area into regular rectangles. However, this process of organizing and dividing the area has the following two problems:

[0033] On the one hand, when the area to be divided is a relatively complex irregular shape, the division process is more complicated and it is easy to divide it into very small area blocks. Therefore, the implementation process is more complicated and affects the efficiency of overall rendering and caching.

[0034] On the other hand, since the area that needs to be rendered each time only needs to be rendered once, it may be difficult to accurately obtain the rendering time of the corresponding area of ​​each small area when dividing irregular areas. Therefore, there may be obstacles that are not easy to implement or inaccurate time consumption that affect the updating of the cache list when implementing the above cache update logic.

[0035] Therefore, the initial solution was improved to obtain the final solution of this implementation. First, the entire page was divided into multiple fixed blocks (e.g., a nine-square grid). Then, each fixed block was used as the smallest unit for cache management. When updating the cache list of this fixed block, it was only saved if the intersection area with this fixed block had the same width as the fixed block.

[0036] Figure 2 This is a schematic diagram of an improved embodiment of the present invention. Figure 3This is a flowchart of an embodiment of the present invention, as follows: Figure 2 and Figure 3 As shown, this embodiment provides a method for PDF page rendering caching, specifically including:

[0037] Step S1: Divide the entire PDF page evenly into multiple fixed blocks;

[0038] In this embodiment, there are nine fixed blocks arranged in a 3x3 grid. In other embodiments, six or eight fixed blocks may be evenly divided, and this invention does not limit the number of evenly divided fixed blocks.

[0039] Step S2: When the page is loaded for the first time, the part to be displayed is rendered for the first time, and the rendered result area is compared with each fixed block that can intersect. If the width of the intersection between the rendered result area and any fixed block is equal to the width of the corresponding fixed block, the rendering result in this fixed block is added to the cache list of this fixed block.

[0040] like Figure 2 As shown, the area to be rendered for the first time is... Figure 2 The area within the light gray box corresponds to nine fixed blocks divided according to a 3x3 grid. The width of the area rendered for the first time intersects with the fixed block in the first row and first column (area 1) and is equal to the width of that fixed block. The width of the area rendered for the first time intersects with the fixed block in the second row and first column (area 2) and is also equal to the width of that fixed block. That is, areas 1 and 2 fill the entire row. Therefore, areas 1 and 2 are added to the cache list of their respective fixed blocks (the fixed block in the first row and first column and the fixed block in the second row and first column).

[0041] Step S3: When the page needs to be rendered again, iterate through and check the cache list stored in each fixed block. If the area to be rendered intersects with the already cached area, call the render function to render the area outside the intersecting area, retrieve the intersecting area from the corresponding cache list, and concatenate the area to be rendered this time with the intersecting area to output the rendering result for display in the application.

[0042] like Figure 2As shown, if a second rendering is required (the area within the dark gray box), the cache list stored in each fixed block is first traversed and checked. It can be found that the area to be rendered this time (the area within the dark gray box) intersects with the already cached areas (the fixed block in the first row and first column and the fixed block in the first row and first column) (areas 3 and 4). Then, the render function is called once to render the area excluding the intersecting area (areas 3 and 4). At this time, the data of areas 3 and 4 can be quickly obtained from the data cached in 1 and 2. Then, the newly rendered area is concatenated with the intersecting area (areas 3 and 4) to obtain the second rendering result. This can improve the efficiency of the second rendering.

[0043] In this embodiment, step S2, which involves splicing the rendered area with the intersecting area, specifically uses the Bitmap's Transform (a function that changes the final display result of the original resource image on the client).

[0044] Step S4: Check the region rendered in step S3 and each fixed block that can intersect. If the width of the intersection between the region rendered in step S3 and any fixed block is equal to the width of the corresponding fixed block, then add the rendering result in this fixed block to the cache list of that fixed block.

[0045] like Figure 2 As shown, the regions rendered in the second rendering intersect with the fixed blocks in the first row and second column, the second row and second column, and the third row and second column, respectively. The widths of the intersecting regions 5, 6, and 7 are equal to the widths of the corresponding fixed blocks. Therefore, the rendering results of regions 5, 6, and 7 in the second rendering are added to the cache list of their respective fixed blocks (the fixed blocks in the first row and second column, the second row and second column, and the third row and second column) for subsequent rendering.

[0046] Step S5: Repeat steps S3 and S4 until rendering is complete.

[0047] Since the cache pool typically has a size limit, it may become full during the continuous rendering and caching of rendered regions. Therefore, the cache list needs to be updated. In this embodiment, the update logic for the cache list can be the same as the initial scheme, specifically as follows:

[0048] Use "resolution + rotation angle" in all cached rendered areas as the first dimension grouping identifier, and then use "rendering time" as the second dimension grouping identifier in a group of cached data with the same resolution and rotation angle.

[0049] Furthermore, a threshold is set in the cache pool. When the size of the overall data in the cache pool reaches the threshold or when a specified size of cache needs to be released in the application layer, the cache is released first based on the group identifier of the first dimension combined with the LRU principle. If the currently cached rendered areas are all of the same resolution and rotation angle, the rendered areas with shorter rendering times are released first based on the rendering time of each rendered area. The rendering time is the time taken for this area to start rendering and finish rendering.

[0050] Compared to the initial solution, the improved solution in this embodiment does not require a complex processing procedure when updating irregular regions to the cache list. Furthermore, since each fixed block is required to fill the entire row (i.e., the width of the intersection of the rendering regions is equal to the width of the fixed block) before caching, the cache management of each fixed block is relatively simple.

[0051] The PDF page rendering caching method provided by this invention, compared with the prior art, improves the rendering efficiency of PDF pages by determining the rendering area that needs to be cached for each fixed block when browsing PDF pages, thereby reducing the size of the page area that needs to be rendered subsequently. This reduces the occurrence of lag when browsing PDF pages.

[0052] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0053] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for PDF page rendering caching, characterized in that, include: Step S1: When the cache is empty, divide the entire PDF page evenly into multiple fixed blocks; Step S2: When the page is loaded for the first time, the part to be displayed is rendered for the first time, and the rendered result area is compared with each fixed block that can intersect. If the width of the intersection between the rendered result area and any fixed block is equal to the width of the corresponding fixed block, the rendering result in this fixed block is added to the cache list of this fixed block. Step S3: When the page needs to be rendered again, iterate through and check the cache list stored in each fixed block. If the area to be rendered intersects with the already cached area, call the render function to render the area outside the intersection area, and concatenate the area to be rendered this time with the already cached intersection area to output the rendering result. Step S4: Check the region rendered in step S3 and each fixed block that can intersect. If the width of the intersection between the region rendered in step S3 and any fixed block is equal to the width of the corresponding fixed block, then add the rendering result in this fixed block to the cache list of that fixed block. Step S5: Repeat steps S3 and S4 until rendering is complete; During the continuous rendering and caching of rendered areas, the cache list needs to be updated. The specific logic for updating the cache list is as follows: Use "resolution + rotation angle" as the first dimension grouping identifier for all cached rendered areas, and then use "rendering time" as the second dimension grouping identifier for a group of cached data with the same resolution and rotation angle. Furthermore, a threshold is set in the cache pool. When the size of the overall data in the cache pool reaches the threshold or when a specified size of cache needs to be released in the application layer, the cache is released first based on the group identifier of the first dimension combined with the LRU principle. If the currently cached rendered areas are all of the same resolution and rotation angle, the rendered areas with shorter rendering times are released first based on the rendering time of each rendered area. The rendering time is the time taken for this area to start rendering and finish rendering.

2. The method for PDF page rendering caching according to claim 1, characterized in that, In step S2, the area rendered this time is stitched together with the intersecting area by using the bitmap's Transform method.

3. The method for PDF page rendering caching according to claim 1, characterized in that, Multiple fixed blocks are divided into nine fixed blocks, distributed in a nine-square grid.

Images