| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Use fz_buffer to wrap and reference count data used in font.
|
|
|
|
|
|
These do no caching, and are intended to be useful for the opengl device.
|
|
For large glyphs, sub pixel positioning is supremely unimportant.
Even for smaller glyphs, we don't need 5*5 possible sub pixel
positions. Base the degree of sub pixel quantisation on the size
of the glyphs.
This should result in better cache use.
We push all the glyph sub positioning logic into fz_render_glyph
(and fz_render_stroked_glyph). This simplifies the calling code.
We also tweak fz_render_glyph so that it updates the transform it
is called with to reflect the sub pixel positioning. This solves
various problems: Firstly, we can round positions both up and down
to achieve a smaller net displacement (e.g. (0.99, 0.99) can go
to (1,1) rather than (0.75, 0.75) if we have a subpixel position
resolution of 1/4 pixels).
Secondly, glyphs that are drawn from outlines will have exactly the
same subpixel changes applied. This is unlikely to be noticable, but
it does mean that baselines should avoid having any shifts in them.
Finally, it enables us to avoid lots of unnecessary copying of
matrices, hopefully reducing overhead.
|
|
Rather than generating fz_pixmaps for glyphs, we generate fz_glyphs.
fz_glyphs can either contain a pixmap, or an RLEd representation
(if it's a mask, and it's smaller).
Should take less memory in the cache, and should be faster to plot.
|
|
* If fz_alpha_from_gray throws in fz_render_t3_glyph, then glyph is leaked.
* If fz_new_image throws in pdf_load_image_imp, then colorspace and mask
are leaked.
* pdf_copy_pattern_gstate overwrites font and softmask without dropping
them first.
|
|
Thanks to zeniko for spotting the problem here.
Type 3 fonts contain a reference to the resources objects required
to render the glyphs. Traditionally these have been freed when the
font is freed. Unfortunately, after recent changes, freeing a PDF
object requires the pdf_document concerned to still exist.
While in most cases the type 3 resources are not used after we have
converted the type3 glyphs to display lists, this is not always the
case. For uncachable Type 3 glyphs (such as those that do not
completely define elements in the graphics state that they use, such
as color or line width), we end up running the glyphs at interpretation
time.
[ Interpretation time = when doing a direct render on the main thread,
or when creating a display list - so also on the main thread. No
multi-threading issues with file access here. ]
The fix implemented here is for each pdf document to keep a list of
the type3 fonts it has created, and to 'decouple' them from the
document when the document is destroyed. The sole effect of this
decoupling is to remove the resources (and the PDF operator buffers)
from the font. These are only ever used during interpretation, and
no further interpretations are possible without the document being
alive anyway, so this should have no net effect on operation, other
than allowing cleanup to proceed cleanly later on.
|
|
|
