| Age | Commit message (Collapse) | Author |
|---|
|
BUG=pdfium:611
Review-Url: https://codereview.chromium.org/2377393002
|
|
BUG=pdfium:597
Review-Url: https://codereview.chromium.org/2345063002
|
|
After this CL: only one global CFX_FontCache used. Any cached items
from it, are released, when they are not being used.
This is restore part of reverted CL:
Original CL: https://codereview.chromium.org/2158023002
Revert reason: BUG=647612
Fix bug CL: https://codereview.chromium.org/2350193003
Review-Url: https://codereview.chromium.org/2350243002
|
|
https://codereview.chromium.org/2158023002/ )
Reason for revert:
Causes heap-use-after-free. See crbug.com/647612.
Original issue's description:
> Fix memory leaking on ClosePage.
> CFX_FontCache refactoring:
> after this CL: Only one global CFX_FontCache used. Any cached items from it, are released, when its are not used.
>
> BUG=79367,48791
>
> The fonts was not cleared after unloading pages.
>
> Test pdf:
>
> http://www.nasa.gov/pdf/750614main_NASA_FY_2014_Budget_Estimates-508.pdf
>
> For this file, we have ~5 fonts per page, which equal ~1 Mb per page.
> In this PDF we have 670 pages, as result after slow scrolling(reading) full document we have ~600 Mb fonts data in memory.
>
> memory usage of PDF Plugin:
> before this CL: ~660 Mb
> after this CL: ~100 Mb
>
> Committed: https://pdfium.googlesource.com/pdfium/+/cde5101eb15b24519e89fa500fe37038bc8e2201
TBR=tsepez@chromium.org,brucedawson@chromium.org,npm@chromium.org,art-snake@yandex-team.ru
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=79367,48791
Review-Url: https://codereview.chromium.org/2350763002
|
|
CFX_FontCache refactoring:
after this CL: Only one global CFX_FontCache used. Any cached items from it, are released, when its are not used.
BUG=79367,48791
The fonts was not cleared after unloading pages.
Test pdf:
http://www.nasa.gov/pdf/750614main_NASA_FY_2014_Budget_Estimates-508.pdf
For this file, we have ~5 fonts per page, which equal ~1 Mb per page.
In this PDF we have 670 pages, as result after slow scrolling(reading) full document we have ~600 Mb fonts data in memory.
memory usage of PDF Plugin:
before this CL: ~660 Mb
after this CL: ~100 Mb
Review-Url: https://codereview.chromium.org/2158023002
|
|
Added a vector of pointers to CFX_Fonts in the class CPDF_Font, so that
fallback fonts may be used. In CPDF_CharPosList::Load, the glyphs for each
character are calculated. When m_Font does not support a character, a fallback
font is selected and the character is rendered using that font. This meant
adding an attribute to FXTEXT_CHARPOS so it knows which font renders it.
Also, methods in fpdf_render_text.cpp now may need to call device drawing
methods multiple times because these only support one font at a time. In
CPDF_TextRenderer::DrawNormalText and in CPDF_TextRenderer::DrawTextPath, the
device drawing method is called as few times as possible by grouping contiguous
characters rendered by the same font. In
CPDF_RenderStatus::DrawTextPathWithPattern, drawing was already done one
character at a time, but precalculating CFX_FaceCache. Now, the face cache is
precalculated for all of the fallback fonts.
The list of fallback fonts does not include tha main font. Otherwise the list
would be of raw pointers to avoid double free problems. For now, the font
Arial is used as fallback. This should fix the issue of not seeing Latin
characters displayed when bad fonts are used. However, this should be improved.
Tested manually using the file in the bug, plus a font directory containing a
font that supports Hangul but not Latin. This font is chosen as the substitute
font, but Latin characters are now being rendered.
Design proposal: go/pdfium_fallbackfonts
BUG=pdfium:358
Review-Url: https://codereview.chromium.org/2276653002
|
|
Review-Url: https://codereview.chromium.org/2269203002
|
|
BUG=pdfium:562
Review-Url: https://codereview.chromium.org/2257313002
|
|
PDFs draw bitmaps with alpha by supplying an
image alpha mask along side the image color data.
The alpha mask may not be the same scale as the
image data. Skia doesn't have a direct mapping
for this draw call, but can come close by using
the internal SkCompositeShader class.
This scales the alpha mask to match the size of
the image data, then puts both in the composite
shader to draw.
There are more things to do:
- Allow Alpha8 or Gray8 to draw scaled to
a matching device (blit doesn't work today)
Temporary code marked with
a TODO implements this functionality.
- Refactor PDFium to allow SkComposeShader's
components to take a matrix.
The latter goal will defer drawing so that PDFium
doesn't resize the mask, discarding resolution,
before Skia has a chance to record it.
Additionally fix drawing text with a negative
font size.
R=reed@google.com,dsinclair@chromium.org,herb@chromium.org
Review-Url: https://codereview.chromium.org/2182763002
|
|
files.
This is the third CL to separate fx_ge into classes, one per file.
All fx_ge.h includes had to be replaced with new includes
The method definitions for CFX_FxgeDevice were not moved to a single file.
These methods are defined in two folders different from fxge/ge, so they were left untouched for now.
Review-Url: https://codereview.chromium.org/2223213002
|
