diff options
| author | Luboš Luňák <l.lunak@suse.cz> | 2012-06-22 17:19:12 +0200 |
|---|---|---|
| committer | Luboš Luňák <l.lunak@suse.cz> | 2012-06-22 17:38:50 +0200 |
| commit | 9a6542d6ef25ccaf78ea26e02693a6c0299b3765 (patch) | |
| tree | a62007979e1371a4f811c72565df6bffda73ab68 /filter | |
| parent | 694dd2cf2a109f233df5011d64defcd4254f9975 (diff) | |
use generic names rather than specific algorithm names when scaling
The Lanczos scaling is of very good quality, but it's rather slow,
which can be very noticeable with large images, so it's not a very
good default for everything. And in general, it's not good to refer
to a specific algorithm when all one usually wants is fast/default/best.
Some of these changes are a bit of a guess between default/best,
but the general logic is that best should be used only for images
that won't be large or where the possible waiting does not matter.
Conflicts:
svtools/source/graphic/grfmgr2.cxx
Change-Id: I53765507ecb7ed167890f6dd05e73fe53ffd0231
Diffstat (limited to 'filter')
| -rw-r--r-- | filter/source/graphicfilter/eps/eps.cxx | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/filter/source/graphicfilter/eps/eps.cxx b/filter/source/graphicfilter/eps/eps.cxx index 9350687613ac..dbe973e47b4a 100644 --- a/filter/source/graphicfilter/eps/eps.cxx +++ b/filter/source/graphicfilter/eps/eps.cxx @@ -499,7 +499,7 @@ void PSWriter::ImplWriteProlog( const Graphic* pPreview ) { Size aSizeBitmap( ( aSizePoint.Width() + 7 ) & ~7, aSizePoint.Height() ); Bitmap aTmpBitmap( pPreview->GetBitmap() ); - aTmpBitmap.Scale( aSizeBitmap, BMP_SCALE_LANCZOS ); + aTmpBitmap.Scale( aSizeBitmap, BMP_SCALE_BEST ); aTmpBitmap.Convert( BMP_CONVERSION_1BIT_THRESHOLD ); BitmapReadAccess* pAcc = aTmpBitmap.AcquireReadAccess(); if ( pAcc ) |