Phil Endecott wrote: > Denis Oliver Kropp wrote: >> Phil Endecott wrote: >>> http://chezphil.org/tmp/dfb_rotation_1.patch >> >> Many thanks. I applied it to 1.1.x (only few conflicts). > > Excellent. I have found one further thing that needed changing: > > --- DirectFB-1.0.0.orig/src/core/gfxcard.c 2007-03-03 > 20:23:01.000000000 +0000 > +++ DirectFB-1.0.0/src/core/gfxcard.c 2007-10-13 19:49:21.000000000 > +0100 > @@ -1582,9 +1582,12 @@ > D_ASSERT( bytes > 0 ); > D_ASSERT( font != NULL ); > > - /* simple prechecks */ > - if (x > state->clip.x2 || y > state->clip.y2 || > - y + font->ascender - font->descender <= state->clip.y1) { > + /* Simple prechecks to eliminate entirely-invisible text. > + (This is only simple for non-rotated text.) > + FIXME this is probably broken for non left-to-right fonts. */ > + if (font->up_unit_x==0.0 && font->up_unit_y==-1.0 && > + (x > state->clip.x2 || y > state->clip.y2 || > + y + font->ascender - font->descender <= state->clip.y1)) { > return; > }
That could explain the problem I had with few of the 270 degree cases. >>> My test program seems to show some off-by-one errors in the bounding >>> box calculations, and perhaps some kerning problems. I plan to fix >>> this. Let me know if you spot any other problems. >> >> Only problem I saw was DSTF_BOTTOMRIGHT with 270 degree rotation. > > In the single glyph example (the first one) I had quite a few text > pixels outside the bounding box. Did you use a different font? > > I was unsure whether it was OK for the text pixels to be _on_ the > bounding box, as drawn; i.e. does DrawRect include the boundary or not? > Maybe it includes some edges but not others? DrawRect() is all inclusive :) >>> I am coming to the opinion that DirectFB would benefit from the use >>> of fractional pixel positions. This was somewhat crystalised when I >>> read this article, which was linked to from LWN: >>> >>> http://antigrain.com/research/font_rasterization/index.html >> >> Indeed, sub pixel positioning and text rendering would be nice. I >> started looking at blitting support for sub pixel rendered fonts, >> but thought with the current flags it's not fully possible. > > OK. I was wondering also about the advance and kerning values that > FreeType returns, which are fractional and which we convert to integer > pixels by truncation. We could easily change this to round-to-nearest. > i.e: > > FT value | Current pixel value | Better(?) pixel value > -64 -2 -1 > -63 -1 -1 > -32 -1 -1 > -31 -1 0 > -1 -1 0 > 0 0 0 > 1 0 0 > 31 0 0 > 32 0 1 > 63 0 1 > 64 1 1 Looks better. I changed the internal values like kerning, advance etc. to fixed point once, with the running variable for the position also fixed, converting to int for the blit, but I did not notice any difference. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
