nanogui: freetype + microwindows + mips
Subject:
Re: [nanogui] freetype + microwindows + mips
From:
####@####.####
Date:
5 Dec 2002 17:14:08 -0000
Message-Id: <OF8D924E1E.DC30A128-ON80256C86.005CA9A0-80256C86.005E2E11@diamond.philips.com>
Hi David,
I'm using Nano-X on both x86 PC and MIPS, with FreeType 2 fonts.
I also have hardware alpha blending between the framebuffer and
video.
I've got some patches to Microwindows to make all this work. They've
been submitted to Greg, and I hope they'll (mostly) be included in
the 0.90 release. You're welcome to have a copy if you like - just
let me know. (They're 330k, too big to send to the list).
Kind regards,
Jon Foster
--
Philips Research Laboratories
David Patmore ####@####.#### wrote:
Greg,
Upgrading to v89 made the socket crash go away (thanks). I still see
strange and wrong behavior with freetype fonts, which I describe:
I'm running the ftdemo application, and switched the font to "arialb".
Software finds the font, loads it and runs, but when it displays the
fonts only little parts appear on the screen. Specifically, it looks
like only the top edges of the capital letters get drawn.
The target system has hardware alpha blending between the framebuffer
and video, so I've mucked with "fblin32.c", but the same changes on the
x86 target don't cause any trouble.
I've been looking at the code in "devdraw.c", because some of the text
image goes through drawpoint and some goes through drawrow. I'll
continue to work on this, but am hoping that you might have seen this
kind of bad behavior before.
Thanks,
David Patmore
On Tue, 2002-12-03 at 09:53, Greg Haerr wrote:
> > This may be a freetype problem, not a microwindows problem, but maybe
> > someone has run into this? Note that the freetype test programs require
> > X, which isn't available on my MIPS target.
>
> This problem could be the result of either alignment issues
> (MIPS can't read a longword from a short boundary, for instance),
> or endian issues. There have been some fixes to both these issues
> with the latest v0.89, I would start with that.
>
> Then, you should look through the FT code looking for any
> cases where disk data is read into a buffer, and then pulled
> out at any size greater than a byte, which will cause a segfault,
> closing the socket. Running nano-X on one console, then switching
> to another and running gdb on the client will show the exact
> offending location.
>
> Regards,
>
> Greg
