nanogui: Thread: Re: I think it is a little bug in font_freetype2.c

> if(blit_instructions.dstx + blit_instructions.dstw >= psd->xvirtres)
 break;

This appears to be a clipping issue.  Without your above fix, the
blit isn't checking to see whether its writing off the end of the 
framebuffer x-direction.  When the character is drawn using
blit, it likely wraps around and disturbs pixels in the next row.

I'll double-check this and likely add the fix to CVS.

Also, you should be using my CVS code for any freetype
work, I've added a number of fixes for Freetype 2, and
also we now support the latest FT version.

Regards,

Greg

if ((blit_instructions.dstw > 0)
       && (blit_instructions.dsth > 0)) {
    GdDrawAreaInternal(psd, &blit_instructions, blit_op);
   }
//The code I added begin.....
if(blit_instructions.dstx + blit_instructions.dstw >= psd->xvirtres)
 break;
//The code I added end.....
 


I think I spoke too soon in the last reply: In looking at
engine/devdraw.c::GdDrawAreaInternal(), the x and width
clipping is being passed to GdClipArea, and should already
be clipping the output to the width remaining on the screen.

This could mean a bug in the low level psd->drawarea
routine when drawing partial width blits.

We would likely need your demo program and the
framebuffer specs in order to debug this more fully.

Regards,

Greg

>    if (error)
    continue;
> error is not zero, which means the later GdDrawAreaInternal is not called 
> at all.


In that case, how is it that your added code gets executed then?  Your
added code is after the continue statement...

Make sure you're using the latest CVS code for FT2.  I fixed
a number of issues with FT2 a month ago.

Also, you can run src/fontdemo2.sh, it displays text off the end of the
screen, perhaps this can be used to duplicate your problem with
demo code.

Regards,

Greg