| Age | Commit message (Collapse) | Author |
|---|
|
Mostly redoing the xps_context to xps_document change and adding
contexts to newly written code.
Conflicts:
apps/pdfapp.c
apps/pdfapp.h
apps/x11_main.c
apps/xpsdraw.c
draw/draw_device.c
draw/draw_scale.c
fitz/base_object.c
fitz/fitz.h
pdf/mupdf.h
pdf/pdf_interpret.c
pdf/pdf_outline.c
pdf/pdf_page.c
xps/muxps.h
xps/xps_doc.c
xps/xps_xml.c
|
|
Extract the grid fitting code from the scaling code and the affine image
drawing code into it's own separate function. This reduces code
duplication. It also allows us to make better allowance for rounding
errors.
Add a voodoo offset in the draw_affine.c code for painting interpolated
images. This gives us the best possible match between all the different
combinations of scaled/unscaled and interpolated/uninterpolated images.
|
|
Kammerer reports 90%+ of CPU time is spent in the image scaling code
for his documents on Android.
In this commit we provide ARM optimised cores for the common scaling
routines (1/2/4 components). Tests indicate this doubles the speed of
rendering for a bitmap heavy PDF file on an HTC desire.
This code is included if ARCH_ARM is defined. If ARCH_THUMB is defined
then extra instructions are added to ensure correct interworking.
We also update the Android jni makefiles to set these defines.
We update the ReadMe.txt with more explicit instructions and update with
more modern ndk/sdk versions.
We update build.xml in line with new sdk releases.
|
|
|
|
Huge pervasive change to lots of files, adding a context for exception
handling and allocation.
In time we'll move more statics into there.
Also fix some for(i = 0; i < function(...); i++) calls.
|
|
To solve bug 691629 we need to ensure that the scaling weights for
every pixel in a gridfitted image sum to 256. I had attempted to
do that by enabling the 'WRAP' code, but this has the effect of
adding too much bias to the outlying source pixels, resulting in
thickened serifs etc.
A better fix is to extend the code that is already present to check
the weights for validity. If an image pixel is completely covered,
then force the weights to 256 by adjusting the largest weight.
This still skews the output slightly but it's a much less visible
result.
|
|
When we calculate weights for scaling, 'wrap' weight calculations
slightly to avoid getting antialiased edge pixels in grid fitted
images.
Seems to solve bug 691629 as much as it's possible to.
|
|
The problem is due to abutting images showing gaps between them.
These gaps are due to a combination of rounding errors, and anti-aliasing
effects on the edge of images.
The solution is to selectively 'grid fit' images.
If an image is part of a type 3 font, we do NOT want to grid fit it, as
this is where the sub pixel positioning makes a huge difference.
If an image is displayed with alpha, then we don't want to grid fit it
(as grid fitting will tend to make the edges of images overlap by 1
pixel, and will hence produce nasty effects).
Otherwise, we will grid fit; Grid fit in this sense is where we expand
an image to completely fill the pixel grid that it touches (i.e. the
extents for the image are expanded to pixel boundaries; no half full
pixels are left around the edges).
The only real change of note here is in how we detect that we are in a
type 3 charproc; we add a new draw device creation function that we call
in the type3 charproc case that sets a flag that the drawing functions
can check.
|
|
Thanks to Zeniko for finding/reporting/patching the problem.
Due to a pointer miscalculation we were overwriting memory. Simple fix.
|
|
|
|
The run-together words are dead! Long live the underscores!
The postscript inspired naming convention of using all run-together
words has served us well, but it is now time for more readable code.
In this commit I have also added the sed script, rename.sed, that I used
to convert the source. Use it on your patches and application code.
|
|
|
