https://issues.apache.org/ooo/show_bug.cgi?id=124313
--- Comment #4 from Armin Le Grand <[email protected]> --- I took a look again and thought more about optimizing ClipRegions at SVG import time. @Regina: When checking the graphic again (break after import) I also saw that the grid lines left and top are created twice/double; another hint to the developers if you can contact them. First check is if the ClipRegion is a rectangle; if no, processing would get expensive but would still be possible writing a primitive processor which detects complete inside/outside. For now, do not optimize no-rectangular ClipRegion. We have three cases when rectangular (empty is already excluded): (a) completely outside (b) completely inside (c) overlap where (c) is !a && !b. We can (a) -> do not create content at all, all is clipped (b) -> no ClipRegion needed, just create content (c) -> no change, create clipped content It showed that (b) should happen often for this concrete case since all content is clipped against the whole diagram area, but it does not. Reason is that the grid lines are '1' unit wide and that getting the range from that primitive works by getting the range from the PolyPolygon (a line in this case) and grows it by 1/2 LineWidth, so the result range is bigger than the ClipRegion and this is correct. I thought about changing this to real geometry creation fallback, but that would be too expensive. I also thought about not expanding in all directions, but this would be a big exception handling for getting the range from a polygon primitive (exceptions only for hor/ver lines, only when line, ...). Thus, (c) happens more often than intended. That brought me to the idea to not use the original ClipRegion for (c), but that there is the chance to optimize the ClipRegion by changin git to the common range used by ClipRegion and content (intersection). This works well and creates minimal ClipRegions, the result still has some but behaves much faster. This is because the expensive part is the unnecessary size of the ClipRegions used. It also shows that to completely avoid this it would be necessary that the authors of the software creating this stuff rethink about creating more minimal SVG files. As explained, in this concrete example not a single one of the 146 ClipRegions is needed. Re-checking with some other stuff, also thinking about the possibility to optimize the used ClipRegion in the Paint mechanism itself in that way... -- You are receiving this mail because: You are on the CC list for the issue. You are the assignee for the issue. You are watching all issue changes.
