2362N/A * Copyright (c) 2008, Oracle and/or its affiliates. All rights reserved. 301N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 301N/A * This code is free software; you can redistribute it and/or modify it 301N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 301N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 301N/A * This code is distributed in the hope that it will be useful, but WITHOUT 301N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 301N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 301N/A * version 2 for more details (a copy is included in the LICENSE file that 301N/A * accompanied this code). 301N/A * You should have received a copy of the GNU General Public License version 301N/A * 2 along with this work; if not, write to the Free Software Foundation, 301N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 301N/A * The function here is used to get a GDI rasterized LCD glyph and place it 301N/A * into the JDK glyph cache. The benefit is rendering fidelity for the 301N/A * most common cases, with no impact on the 2D rendering pipelines. 301N/A * Requires that the font and graphics are unrotated, and the scale is 301N/A * a simple one, and the font is a TT font registered with windows. 301N/A * Those conditions are established by the calling code. 301N/A * - Receives the family name, style, and size of the font 301N/A * and creates a Font object. 301N/A * - Create a surface from which we can get a DC : must be 16 bit or more. 301N/A * Ideally we'd be able to specify the depth of this, but in practice we 301N/A * have to accept it will be the same as the default screen. 301N/A * - Selects the GDI font on to the device 301N/A * - Uses GetGlyphOutline to estimate the bounds. 301N/A * - Creates a DIB on to which to blit the image. 301N/A * - Creates a GlyphInfo structure and copies the GDI glyph and offsets 301N/A * into the glyph which is returned. 301N/A/* Some of these are also defined in awtmsg.h but I don't want a dependency 301N/A * on that here. They are needed here - and in awtmsg.h - until we 301N/A * move up our build to define WIN32_WINNT >= 0x501 (ie XP), since MS 301N/A * headers will not define them otherwise. 301N/A#
endif //SPI_GETFONTSMOOTHINGTYPE 301N/A#
endif //SPI_GETFONTSMOOTHINGCONTRAST 301N/A#
endif //SPI_GETFONTSMOOTHINGORIENTATION 301N/A#
endif //FE_FONTSMOOTHINGORIENTATIONBGR 301N/A#
endif //FE_FONTSMOOTHINGORIENTATIONRGB 301N/A /* Need at least XP which is 5.1 */ 301N/A /* Probably no such glyph - ie the font wasn't the one we expected. */ 301N/A /* Don't handle "invisible" glyphs in this code */ 301N/A /* GetGlyphOutline pre-dates cleartype and I'm not sure that it will 301N/A * account for all pixels touched by the rendering. Need to widen, 301N/A * and also adjust by one the x position at which it is rendered. 301N/A * The extra pixels of width are used as follows : 301N/A * One extra pixel at the left and the right will be needed to absorb 301N/A * the pixels that will be touched by filtering by GDI to compensate 301N/A * However there seem to be some cases where GDI renders two extra 301N/A * pixels to the right, so we add one additional pixel to the right, 301N/A * and in the code that copies this to the image cache we test for 301N/A * the (rare) cases when this is touched, and if its not reduce the 301N/A * stated image width for the blitting loops. 301N/A * For fractional metrics : 301N/A * One extra pixel at each end to account for sub-pixel positioning used 301N/A * when fractional metrics is on in LCD mode. 301N/A * The pixel at the left is needed so the blitting loop can index into 301N/A * that a byte at a time to more accurately position the glyph. 301N/A * The pixel at the right is needed so that when such indexing happens, 301N/A * the blitting still can use the same width. 301N/A * Consequently the width that is specified for the glyph is one less 301N/A * than that of the actual image. 301N/A * Note that in the FM case as a consequence we need to adjust the 301N/A * position at which GDI renders, and the declared width of the glyph 301N/A * See the if (fm) {} cases in the code. 301N/A * For the non-FM case, we not only save 3 bytes per row, but this 301N/A * prevents apparent glyph overlapping which affects the rendering 301N/A * performance of accelerated pipelines since it adds additional 301N/A * read-back requirements. 301N/A /* DIB scanline must end on a DWORD boundary. We specify 3 bytes per pixel, 301N/A * so must round up as needed to a multiple of 4 bytes. 301N/A /* The glyph cache image must be a multiple of 3 bytes wide. */ 301N/A /* Must use desktop DC to create a bitmap of that depth */ 301N/A /* Set text color to white, background to black. */ 301N/A /* adjust rendering position */ 301N/A /* Now get the image into a DIB. 301N/A * MS docs for GetDIBits says the compatible bitmap must not be 301N/A * selected into a DC, so restore the original first. 301N/A if (
err == 0) {
/* GetDIBits failed. */ 301N/A /* Now copy glyph image into a GlyphInfo structure and return it. 301N/A * NB the xadvance calculated here may be overwritten by the caller. 301N/A * 1 is subtracted from the bitmap width to get the glyph width, since 301N/A * that extra "1" was added as padding, so the sub-pixel positioning of 301N/A * fractional metrics could index into it. 301N/A /* DIB 24bpp data is always stored in BGR order, but we usually 301N/A * need this in RGB, so we can't just memcpy and need to swap B and R. 301N/A * Also need to apply inverse gamma adjustment here. 301N/A * We re-use the variable "extra" to see if the last pixel is touched 301N/A * at all. If its not we can reduce the glyph image width. This comes 301N/A * into play in some cases where GDI touches more pixels than accounted 301N/A * for by increasing width by two pixels over the B&W image. Whilst 301N/A * the bytes are in the cache, it doesn't affect rendering performance 301N/A * of the hardware pipelines.