stellarium-pubdevel

[Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

I can reproduce most of the font corruption issues that have been 
reported and have found the problem to be with QPainter::drawText, which 
is called from StelPainter.  Exactly what's causing the problems is 
unknown.  However, it is likely that an upstream fix is required, but 
that won't be easy if they can't reproduce the problem and it may never 
happen for OpenGL1 (if I've understood some forum posts correctly).

As a workaround until this is fixed properly (if it ever is), I've put 
together a replacement for StelPainter::drawText that does not rely on 
QPainter::drawText.  It is based on the work of NeHe (who will be 
familiar to most people who have coded OpenGL) - see 
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=13.

The code is pretty well commented, but here's a summary:
- the OS API and OpenGL are used to create 2D bitmap or 3D outline fonts
- there is a separate glyph for each character
- text is then drawn by displaying the appropriate glyphs

There's a new class named ReplacementFont (my imagination was lacking) 
that stores the generate font characters and does the drawing.  At this 
stage, I've just dumped all the code into StelPainter.cpp (to save time 
compiling while working with the new class declaration).  It's still a 
bit rough (and needs some class renaming!) but it works.  There are a 
few small things to do (all of which is commented).  Special items include:

- star labels are black for me but planet/grid line labels, etc., are 
okay (they were okay but I've done something?)
- 3D outline fonts, required for text rotation and scaling need the 
correct GL transforms
- it is only used in StelPainter, but fixing that solves all other font 
issues (for me at least)
- it is Windows only (but easily ported to Mac and Linux)

Please have a look and let me know if you're interested in trying this 
as a temporary solution.  It's available on Launchpad:
   bzr <CMD> lp:~scrupeus/stellarium/fix-fonts
where <CMD> = pull or branch or merge, depending what you want to do.

If there is interest, some help with the commented TODO items would be 
appreciated (most will be straightforward for the OpenGL gurus out 
there).  Feel free to hack away at the 'ReplacementFont' class as well.

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

Continuing...

If there is interest in implementing this, here's what I propose:
- fix the main issues (should be easy enough)
- push out a patch to a few people experiencing problems (I've got a list)
- ensure it works with various graphics cards and non-Latin character 
sets (it should)
- if okay, clean it up and port to Mac/Linux (should also not be difficult)

Or if someone can find a fix for QPainter::drawText, that would be even 
better ;)

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

Hi thanks for the effort! This is quite similar to the previous code we had
in Stellarium, but we had to change to support international characters. I
think you code suffers from the same problems that our had. Namely, if you
want to display e.g. a chinese character, you need to use a font which
supports it, otherwise you end up with a broken character. Qt solves this by
reverting to other fonts if it sees that it's not supported by the base
font. Also your code won't handle characters's linking, like in arabic.

Actually there is also another quite easy way to fix the problem: render the
text in a QImage or QPixmap and just dump the image on the screen. This is
is probably easier than your solution, and could even also allow
performances improvement by using caching of the whole words. I never did it
so far because I always hoped that Qt will fix the problem, but now it
indeed seems that they lack motivation for working on that..
Fabien

On Mon, Jun 21, 2010 at 17:16, Peter Mousley <scr...@mo...>wrote:

> Continuing...
>
> If there is interest in implementing this, here's what I propose:
> - fix the main issues (should be easy enough)
> - push out a patch to a few people experiencing problems (I've got a list)
> - ensure it works with various graphics cards and non-Latin character
> sets (it should)
> - if okay, clean it up and port to Mac/Linux (should also not be difficult)
>
> Or if someone can find a fix for QPainter::drawText, that would be even
> better ;)
>
> Peter
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 2:17, Fabien Chéreau wrote:
> Hi thanks for the effort! This is quite similar to the previous code 
> we had in Stellarium, but we had to change to support international 
> characters. I think you code suffers from the same problems that our 
> had. Namely, if you want to display e.g. a chinese character, you need 
> to use a font which supports it, otherwise you end up with a broken 
> character. Qt solves this by reverting to other fonts if it sees that 
> it's not supported by the base font. Also your code won't handle 
> characters's linking, like in arabic.
>
> Actually there is also another quite easy way to fix the problem: 
> render the text in a QImage or QPixmap and just dump the image on the 
> screen. This is is probably easier than your solution, and could even 
> also allow performances improvement by using caching of the whole 
> words. I never did it so far because I always hoped that Qt will fix 
> the problem, but now it indeed seems that they lack motivation for 
> working on that..
> Fabien

I can't read Chinese but it looks okay to me (the planet labels match 
the info box characters - they overlap slightly but that should be easy 
to fix).  You are correct about Arabic; it will not link the 
characters.  But which is better - characters that aren't linked or 
characters that looked like squashed tomatoes?  It would be best left to 
someone fluent in Arabic, etc.  The font can be anything (just remove 
the hard-coded selection I put in and pick up the current app font), 
although for me it uses DejaVu Sans for Arabic and Chinese by default 
anyway.

Should it prove usable, this type of code should only be a fall-back, 
not the default; it should be similar to the already included OpenGL 
'--safe-mode'. Perhaps '--safe-fonts'?  Or, just make it an extension of 
the existing --safe-mode, i.e. if safe-mode is active, use the alternate 
text drawing method.

But that's jumping ahead - this (or something else) needs testing.  What 
I would like to know is, "Do you want this as a solution (in which case 
I'll get it properly tested and finished) or do you want to use 
something else?"

RE: Other solutions

I'm all for a simpler/better solution.  But this code is simple to use, 
fast when running and once the 'ReplacementFont' code is moved out of 
StelPainter, it would hardly look any different to what's there now.  
I'll take a look at QImage/QPixmap if you want, but you could probably 
do it in 10% of the time (I'll then test it for you).

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

On Tue, Jun 22, 2010 at 03:02, Peter Mousley <scr...@mo...>wrote:

> On 22/06/2010 2:17, Fabien Chéreau wrote:
> > Hi thanks for the effort! This is quite similar to the previous code
> > we had in Stellarium, but we had to change to support international
> > characters. I think you code suffers from the same problems that our
> > had. Namely, if you want to display e.g. a chinese character, you need
> > to use a font which supports it, otherwise you end up with a broken
> > character. Qt solves this by reverting to other fonts if it sees that
> > it's not supported by the base font. Also your code won't handle
> > characters's linking, like in arabic.
> >
> > Actually there is also another quite easy way to fix the problem:
> > render the text in a QImage or QPixmap and just dump the image on the
> > screen. This is is probably easier than your solution, and could even
> > also allow performances improvement by using caching of the whole
> > words. I never did it so far because I always hoped that Qt will fix
> > the problem, but now it indeed seems that they lack motivation for
> > working on that..
> > Fabien
>
> I can't read Chinese but it looks okay to me (the planet labels match
> the info box characters - they overlap slightly but that should be easy
> to fix).


This is surprising, DejaVu doesn't support Chinese characters. Probably the
win32 API (CreateFontW) also provides a replacement character from another
font by itself.


> You are correct about Arabic; it will not link the
> characters.  But which is better - characters that aren't linked or
> characters that looked like squashed tomatoes?  It would be best left to
> someone fluent in Arabic, etc.  The font can be anything (just remove
> the hard-coded selection I put in and pick up the current app font),
> although for me it uses DejaVu Sans for Arabic and Chinese by default
> anyway.
>
Should it prove usable, this type of code should only be a fall-back,
> not the default; it should be similar to the already included OpenGL
> '--safe-mode'. Perhaps '--safe-fonts'?  Or, just make it an extension of
> the existing --safe-mode, i.e. if safe-mode is active, use the alternate
> text drawing method.
>
> But that's jumping ahead - this (or something else) needs testing.  What
> I would like to know is, "Do you want this as a solution (in which case
> I'll get it properly tested and finished) or do you want to use
> something else?"
>

I am quite unsure. My main subjective feeling is that it would be a
regression to come back to such hacks after all our efforts to move to Qt
completely. But I also agree that this bug is so annoying that we should
really do something, and I really appreciate your efforts!


> RE: Other solutions
>
> I'm all for a simpler/better solution.  But this code is simple to use,
> fast when running and once the 'ReplacementFont' code is moved out of
> StelPainter, it would hardly look any different to what's there now.
> I'll take a look at QImage/QPixmap if you want, but you could probably
> do it in 10% of the time (I'll then test it for you).
>
>
Before deciding whether to merge or not in trunk, I would really like to see
an alternative Qt based solution, not involving win32 API. I just played a
bit with the QImage/QPixmap idea, and it works more or less, although it's a
bit slow. See the attached 10 lines patch.

Fabien

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 20:16, Fabien Chéreau wrote:
>
> This is surprising, DejaVu doesn't support Chinese characters. 
> Probably the win32 API (CreateFontW) also provides a replacement 
> character from another font by itself.
> <snip>
> Before deciding whether to merge or not in trunk, I would really like 
> to see an alternative Qt based solution, not involving win32 API. I 
> just played a bit with the QImage/QPixmap idea, and it works more or 
> less, although it's a bit slow. See the attached 10 lines patch.
>
> Fabien
>
I don't understand what's happening with Chinese either, but it looks 
good and that's what's returned from Win32 API after creating the bitmap 
font and setting it as active (if you can believe Windows ;).  DejaVu 
Sans does have Chinese code pages, but not all the characters, so who 
knows?  I've updated my branch on LP to handle right-to-left and use the 
app's current font.

Re merging with trunk, that's a long way off.  But this would be a good 
time to think about exactly what 'trunk' is, now you're using bzr.  My 
2c is that it should be reserved for properly tested and stable code, 
with another experimental/development/sid branch for code that may end 
up being trashed or heavily modified - keep trunk relatively 'clean' and 
ready for a release at almost any time.  You don't want too many 
branches to maintain but people may get a little cranky if too many 
half-baked commits end up in trunk.  Plenty of suggestions in the bzr 
manual, etc.

I'll take a look at your code.

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 20:16, Fabien Chéreau wrote:
> Before deciding whether to merge or not in trunk, I would really like 
> to see an alternative Qt based solution, not involving win32 API. I 
> just played a bit with the QImage/QPixmap idea, and it works more or 
> less, although it's a bit slow. See the attached 10 lines patch.
>
> Fabien
>

Attached is an alternative that is much closer to working.  The two main 
issues are:

1/ star labels only show correctly when a cluster/nebula is selected 
(need the pulsing selection box)
   - planet labels, grid labels, etc., are fine
   - star labels are actually there, but they're black boxes

2/ text is not rotated (grid labels for example)
   - is this a limitation of bitmap images?

Both of these are actually the same symptoms I have with my 'replacement 
font' solution - I must be overlooking something obvious re the star 
labels.  Using the 3D outline fonts was also my solution for getting 
rotated text (you can't rotate the 2D bitmap fonts).

Besides those two problems, the frame rate is better and the text looks 
good.  With some caching (perhaps even without?), I think it may be good 
enough as a workaround when needed, and at least worth getting a few 
people to test (as previously mentioned, I've kept track of several 
people and can take care of getting it tested).

I'd appreciate some feedback re those two issues though.

Peter

PS My local bzr repo has just b0rked itself :(  Fortunately, anything 
important is also saved as patch/diff files.  Hg anyone?

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

On Tue, Jun 22, 2010 at 16:28, Peter Mousley <scr...@mo...>wrote:

> On 22/06/2010 20:16, Fabien Chéreau wrote:
>
>> Before deciding whether to merge or not in trunk, I would really like to
>> see an alternative Qt based solution, not involving win32 API. I just played
>> a bit with the QImage/QPixmap idea, and it works more or less, although it's
>> a bit slow. See the attached 10 lines patch.
>>
>> Fabien
>>
>>
> Attached is an alternative that is much closer to working.  The two main
> issues are:
>
> Good! That should even be faster, by bypassing the QPainter stuff.


> 1/ star labels only show correctly when a cluster/nebula is selected (need
> the pulsing selection box)
>  - planet labels, grid labels, etc., are fine
>  - star labels are actually there, but they're black boxes
>
>
try to glEnable(GL_BLEND)


> 2/ text is not rotated (grid labels for example)
>  - is this a limitation of bitmap images?
>
>

glDrawPixel doesn't use the matrix. Try to draw the texture using a real gl
call.

Thanks a lot! If you make taht working you'll be a hero for ATI users ;)

Both of these are actually the same symptoms I have with my 'replacement
> font' solution - I must be overlooking something obvious re the star labels.
>  Using the 3D outline fonts was also my solution for getting rotated text
> (you can't rotate the 2D bitmap fonts).
>
> Besides those two problems, the frame rate is better and the text looks
> good.  With some caching (perhaps even without?), I think it may be good
> enough as a workaround when needed, and at least worth getting a few people
> to test (as previously mentioned, I've kept track of several people and can
> take care of getting it tested).
>
> I'd appreciate some feedback re those two issues though.
>
> Peter
>
> PS My local bzr repo has just b0rked itself :(  Fortunately, anything
> important is also saved as patch/diff files.  Hg anyone?
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 23/06/2010 0:34, Fabien Chéreau wrote:
>
> On Tue, Jun 22, 2010 at 16:28, Peter Mousley <scr...@mo... 
> <mailto:scr...@mo...>> wrote:
>
>     On 22/06/2010 20:16, Fabien Chéreau wrote:
>
>         Before deciding whether to merge or not in trunk, I would
>         really like to see an alternative Qt based solution, not
>         involving win32 API. I just played a bit with the
>         QImage/QPixmap idea, and it works more or less, although it's
>         a bit slow. See the attached 10 lines patch.
>
>         Fabien
>
>
>     Attached is an alternative that is much closer to working.  The
>     two main issues are:
>
> Good! That should even be faster, by bypassing the QPainter stuff.
>
>     1/ star labels only show correctly when a cluster/nebula is
>     selected (need the pulsing selection box)
>      - planet labels, grid labels, etc., are fine
>      - star labels are actually there, but they're black boxes
>
>
> try to glEnable(GL_BLEND)
I had expected it was already set (which, upon checking, it is), so 
hadn't bothered with it.  Added it anyway - makes no difference.  I've 
also noticed that the star labels disappear when constellation art is 
on, but the planet labels are still okay.  What's different between 
planet and star labels? (I'm guessing there must be some GL state 
different? But what?)

>     2/ text is not rotated (grid labels for example)
>      - is this a limitation of bitmap images?
>
>
> glDrawPixel doesn't use the matrix. Try to draw the texture using a 
> real gl call.
>
As an infamous politician here once said, "Please explain!"


> Thanks a lot! If you make taht working you'll be a hero for ATI users ;)
>
>
I've been delaying purchase of a new laptop because the one I want only 
comes with ATI.  Hadn't really thought that Stellarium may not work, but 
I need a replacement soon - need to get this bug fixed!

I'll look at it again in the morning.

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

if ((str=="HIP 19525") || (str == "Mercury"))
{
	static bool hip = false;
	static bool mer = false;
	if ((!hip && (str == "HIP 19525")) || (!mer && (str == "Mercury")))
	{
		if (str == "HIP 19525")
			hip = true;
		if (str == "Mercury")
			mer = true;

		qDebug() << "***** GL STATE: " << str << " *****";
		qDebug() << "GL_ALPHA_TEST: " << (int)glIsEnabled(GL_ALPHA_TEST);
		qDebug() << "GL_AUTO_NORMAL: " << (int)glIsEnabled(GL_AUTO_NORMAL);
		qDebug() << "GL_BLEND: " << (int)glIsEnabled(GL_BLEND);
		qDebug() << "GL_COLOR_MATERIAL: " << (int)glIsEnabled(GL_COLOR_MATERIAL);
		qDebug() << "GL_CULL_FACE: " << (int)glIsEnabled(GL_CULL_FACE);
		qDebug() << "GL_DEPTH_TEST: " << (int)glIsEnabled(GL_DEPTH_TEST);
		qDebug() << "GL_DITHER: " << (int)glIsEnabled(GL_DITHER);
		qDebug() << "GL_FOG: " << (int)glIsEnabled(GL_FOG);
		qDebug() << "GL_LIGHTING: " << (int)glIsEnabled(GL_LIGHTING);
		qDebug() << "GL_LINE_SMOOTH: " << (int)glIsEnabled(GL_LINE_SMOOTH);
		qDebug() << "GL_LINE_STIPPLE: " << (int)glIsEnabled(GL_LINE_STIPPLE);
		qDebug() << "GL_LOGIC_OP: " << (int)glIsEnabled(GL_LOGIC_OP);
		qDebug() << "GL_MAP1_COLOR_4: " << (int)glIsEnabled(GL_MAP1_COLOR_4);
		qDebug() << "GL_MAP1_INDEX: " << (int)glIsEnabled(GL_MAP1_INDEX);
		qDebug() << "GL_MAP1_NORMAL: " << (int)glIsEnabled(GL_MAP1_NORMAL);
		qDebug() << "GL_MAP1_TEXTURE_COORD_1: " << (int)glIsEnabled(GL_MAP1_TEXTURE_COORD_1);
		qDebug() << "GL_MAP1_TEXTURE_COORD_2: " << (int)glIsEnabled(GL_MAP1_TEXTURE_COORD_2);
		qDebug() << "GL_MAP1_TEXTURE_COORD_3: " << (int)glIsEnabled(GL_MAP1_TEXTURE_COORD_3);
		qDebug() << "GL_MAP1_TEXTURE_COORD_4: " << (int)glIsEnabled(GL_MAP1_TEXTURE_COORD_4);
		qDebug() << "GL_MAP1_VERTEX_3: " << (int)glIsEnabled(GL_MAP1_VERTEX_3);
		qDebug() << "GL_MAP1_VERTEX_4: " << (int)glIsEnabled(GL_MAP1_VERTEX_4);
		qDebug() << "GL_MAP2_COLOR_4: " << (int)glIsEnabled(GL_MAP2_COLOR_4);
		qDebug() << "GL_MAP2_INDEX: " << (int)glIsEnabled(GL_MAP2_INDEX);
		qDebug() << "GL_MAP2_NORMAL: " << (int)glIsEnabled(GL_MAP2_NORMAL);
		qDebug() << "GL_MAP2_TEXTURE_COORD_1: " << (int)glIsEnabled(GL_MAP2_TEXTURE_COORD_1);
		qDebug() << "GL_MAP2_TEXTURE_COORD_2: " << (int)glIsEnabled(GL_MAP2_TEXTURE_COORD_2);
		qDebug() << "GL_MAP2_TEXTURE_COORD_3: " << (int)glIsEnabled(GL_MAP2_TEXTURE_COORD_3);
		qDebug() << "GL_MAP2_TEXTURE_COORD_4: " << (int)glIsEnabled(GL_MAP2_TEXTURE_COORD_4);
		qDebug() << "GL_MAP2_VERTEX_3: " << (int)glIsEnabled(GL_MAP2_VERTEX_3);
		qDebug() << "GL_MAP2_VERTEX_4: " << (int)glIsEnabled(GL_MAP2_VERTEX_4);
		qDebug() << "GL_NORMALIZE: " << (int)glIsEnabled(GL_NORMALIZE);
		qDebug() << "GL_POINT_SMOOTH: " << (int)glIsEnabled(GL_POINT_SMOOTH);
		qDebug() << "GL_POLYGON_SMOOTH: " << (int)glIsEnabled(GL_POLYGON_SMOOTH);
		qDebug() << "GL_POLYGON_STIPPLE: " << (int)glIsEnabled(GL_POLYGON_STIPPLE);
		qDebug() << "GL_SCISSOR_TEST: " << (int)glIsEnabled(GL_SCISSOR_TEST);
		qDebug() << "GL_STENCIL_TEST: " << (int)glIsEnabled(GL_STENCIL_TEST);
		qDebug() << "GL_TEXTURE_1D: " << (int)glIsEnabled(GL_TEXTURE_1D);
		qDebug() << "GL_TEXTURE_2D: " << (int)glIsEnabled(GL_TEXTURE_2D);
		qDebug() << "GL_TEXTURE_GEN_Q: " << (int)glIsEnabled(GL_TEXTURE_GEN_Q);
		qDebug() << "GL_TEXTURE_GEN_R: " << (int)glIsEnabled(GL_TEXTURE_GEN_R);
		qDebug() << "GL_TEXTURE_GEN_S: " << (int)glIsEnabled(GL_TEXTURE_GEN_S);
		qDebug() << "GL_TEXTURE_GEN_T: " << (int)glIsEnabled(GL_TEXTURE_GEN_T);
	}
}

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 23/06/2010 1:55, Peter Mousley wrote:
> Problem 1 solved!  I added code to output if 42 GL capabilities were 
> enabled or not, for both a star and a planet (just for some amusement, 
> see attached).  Two were different; GL_BLEND and GL_TEXTURE_2D were 
> both enabled for stars but not for planets.  Disabling GL_BLEND did 
> not help, but disabling GL_TEXTURE fixed it.  Star labels now work 
> properly with both OpenGL1 and OpenGL2 :-D
> As a bonus, the frame rate is up: (20 FPS using QPainter::drawImage; 
> 30 FPS with GL_TEXTURE_2D enabled; and almost 40 FPS now (with 
> GL_BLEND disabled, which still looks pretty good, FPS is above 40).  
> As a comparison, using QPainter::drawText direct to QGLWidget gives 
> just under 60 FPS - when it's working.
>
> Now I just need rotated text.  Fabien?  Anyone else?
>
Code available on Launchpad:
lp:~scrupeus/stellarium/fix-fonts-gl

Some TODO's are included as comments.
Any feedback/assistance welcome.
If anyone with font problems is able to test, that would be much 
appreciated.

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

I've changed to using textures for the labels and it looks good.  As a 
bonus, FPS is 15-20% higher than the 0.10.5 release when lots of labels 
are visible; it even works well with grid lines on.

There is some cleaning up to do and it could be better integrated into 
StelPainter (for example, all code is lumped together for easy editing 
at the moment).  However, I believe this is ready for others to test and 
it's not worth spending extra effort at this time.  For testing now, I'm 
not so interested in "the text is upside down", etc.  I mainly want to 
hear from people with existing font corruption problems: Does the text 
look good?  Can you read it now?  (Note: If you're forcing OpenGL1, 
please also test with OpenGL2.)  For those without existing problems, 
does it work for you?  Are the frame rates high?

Bzr branch is available at:
     lp:~scrupeus/stellarium/fix-fonts-gltex

Fabien/Bogdan - If this is considered okay for testing, could someone 
post a binary patch?  If you don't want to do that, I can host myself 
(Windows and possibly Linux - not Mac).  Either way, once a patch is 
available, I'll chase up everyone who posted a font-related bug report 
and get them to test it.

Fingers crossed.

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 30/06/2010 22:12, Fabien Chéreau wrote:
> Hi Peter,
> Sorry for the delay (I'm back from a long WE in Irland), i just had a
> look at the code, which I like in general, but I have a couple of
> comments:
>   - You should try to use the QCache class
> (http://doc.qt.nokia.com/4.6/qcache.html) for managing the texture
> cache instead of reimplementing similar features in StringTextureList.
>   - You should avoid all gl calls which are not compatible with
> opengl3, i.e. glBegin/glEnd, and glTranslate/glRotate, instead try to
> use vertex arrays, and to compute the rotation in the code itself.
>   - Try to use QGLContext methods for creating/binding/deleting
> textures. In StelPainter you have access to the QGLContext using the
> static member StelPainter::glContext.
>
> All those comment are implementation details and I generally agree
> with the concept :)
> Fabien
>    
A Frenchman in Ireland?  You would had to have been very brave two weeks 
ago, but now I suspect they couldn't stop laughing at you ;)

I had taken a quick look at QCache (and QPixmapCache) but you would need 
to hash "string + font + font size" to generate a key.  The obvious 
solution for generating the hash would be QHash, but alas that is for a 
hash table (why isn't is called 'QHashTable'?).  Being impatient, I just 
spent two minutes writing a custom cache.  (I do actually have my own 
hash and even 'hashing cache' classes for my day job, but just wanted 
something simple and easy to follow.  I also wanted to minimise the use 
of Qt to have the highest probability of it working.  But I do agree - 
ultimately it would be best to make use of what's available in Qt if it 
works.)

Are you sure about glRotate, etc., not being compatible with OpenGL 
1.3?  I saw uses of it dating back to at least the 1.1 timeframe, but 
they may have been implementation dependant.  (Do you have a link to a 
list of commonly available functions for each version?)  Again though, I 
just wanted some quick and easy to implement for testing.

I'll have a look at QGLContext.

If it's okay with you, I'd like to push this out to a few people with 
the font problem.  Given most of them don't compile code, that means a 
binary.  I can put a binary patch on my own web server or you (Bogdan?) 
could do it via the Stellarium site.  Let me know.  (I would like to 
make one addition first though - output more OpenGL version info in the 
log.  I can make a patch for this soon.)

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 2:17, Fabien Chéreau wrote:
> Hi thanks for the effort! This is quite similar to the previous code 
> we had in Stellarium, but we had to change to support international 
> characters. I think you code suffers from the same problems that our 
> had. Namely, if you want to display e.g. a chinese character, you need 
> to use a font which supports it, otherwise you end up with a broken 
> character. Qt solves this by reverting to other fonts if it sees that 
> it's not supported by the base font. Also your code won't handle 
> characters's linking, like in arabic.
>
> Actually there is also another quite easy way to fix the problem: 
> render the text in a QImage or QPixmap and just dump the image on the 
> screen. This is is probably easier than your solution, and could even 
> also allow performances improvement by using caching of the whole 
> words. I never did it so far because I always hoped that Qt will fix 
> the problem, but now it indeed seems that they lack motivation for 
> working on that..
> Fabiens://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel

What I don't think I've mentioned before is that when QPainter::drawText 
is commented out in StelPainter (i.e. no star/planet/grid labels are 
drawn), the toolbar text is okay for me.  However, I think I also had to 
avoid the dreaded DejaVu Sans 13 when doing that (12 or 14 okay).  
Interestingly, 13 is okay with a replacement drawing method.

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

On Tue, Jun 22, 2010 at 14:32, Peter Mousley <scr...@mo...>wrote:

> On 22/06/2010 20:16, Fabien Chéreau wrote:
> > Before deciding whether to merge or not in trunk, I would really like
> > to see an alternative Qt based solution, not involving win32 API. I
> > just played a bit with the QImage/QPixmap idea, and it works more or
> > less, although it's a bit slow. See the attached 10 lines patch.
> >
> > Fabien
> >
>
> When you said "it's a bit slow", I thought, "oh, probably drops a couple
> FPS."  Two minutes later, I still didn't have any text, no toolbar, no
> infobar, no dialogues...  Did have some stars though!
>
>
Seems more like a failure!


> Switched to GL1 and it runs, but FPS is about 1/3 drawing directly.  I
> removed the class constructions out of the last two lines (why are they
> needed?) and got about 2 FPS improvement (yawn...).  Note: You also need
> to move the text up by rect.y() in drawPixmap to put the text just off
> the top-right of the object.  Here's what I used:
>         painter.drawText(-rect.x(), -rect.y(), str);
>         qPainter->drawPixmap(0, rect.y(), tmp);
>

Thanks, it's better like that.

I don't think it's worth sending out at this stage - FPS is low and GL2
> doesn't work for me, so probably won't for others.  (Keep in mind I'm
> running a deliberately botched system to test these problems, but it
> seems to match what others get - I'm sure it would run with GL2 if I got
> my system back to normal.)
>

I'm using GL2 and it works just fine with my nvidia, the performance drop is
not that high on my config. What do you mean by botched? I think I missed
that probably in a previous email.
The performance can be greatly accelerated by using caching of the openGL
textures or of the pixmaps. But before going further with optimizations it's
important to see if it works at all, and apparently it doesn't for you..
Could you please investigate on that?

Fab

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 23:31, Fabien Chéreau wrote:
>
>
> On Tue, Jun 22, 2010 at 14:32, Peter Mousley <scr...@mo... 
> <mailto:scr...@mo...>> wrote:
>
>     On 22/06/2010 20:16, Fabien Chéreau wrote:
>     > Before deciding whether to merge or not in trunk, I would really
>     like
>     > to see an alternative Qt based solution, not involving win32 API. I
>     > just played a bit with the QImage/QPixmap idea, and it works more or
>     > less, although it's a bit slow. See the attached 10 lines patch.
>     >
>     > Fabien
>     >
>
>     When you said "it's a bit slow", I thought, "oh, probably drops a
>     couple
>     FPS."  Two minutes later, I still didn't have any text, no toolbar, no
>     infobar, no dialogues...  Did have some stars though!
>
>
> Seems more like a failure!
Depends how much you like stars.
>
>     Switched to GL1 and it runs, but FPS is about 1/3 drawing directly.  I
>     removed the class constructions out of the last two lines (why are
>     they
>     needed?) and got about 2 FPS improvement (yawn...).  Note: You
>     also need
>     to move the text up by rect.y() in drawPixmap to put the text just off
>     the top-right of the object.  Here's what I used:
>             painter.drawText(-rect.x(), -rect.y(), str);
>             qPainter->drawPixmap(0, rect.y(), tmp);
>
>
> Thanks, it's better like that.
>
>     I don't think it's worth sending out at this stage - FPS is low
>     and GL2
>     doesn't work for me, so probably won't for others.  (Keep in mind I'm
>     running a deliberately botched system to test these problems, but it
>     seems to match what others get - I'm sure it would run with GL2 if
>     I got
>     my system back to normal.)
>
>
> I'm using GL2 and it works just fine with my nvidia, the performance 
> drop is not that high on my config. What do you mean by botched? I 
> think I missed that probably in a previous email.
> The performance can be greatly accelerated by using caching of the 
> openGL textures or of the pixmaps. But before going further with 
> optimizations it's important to see if it works at all, and apparently 
> it doesn't for you.. Could you please investigate on that?
>
> Fab
>
With the latest available Windows and graphics card updates (nvidia), 
everything works for me (at least it used to - haven't tried for a few 
weeks).  However, I'd previously had problems reminiscent of what others 
report, so I wound-back the system to the point where I could replicate 
the font problems.  The solution for me is simple - reinstall the 
updates and live a long and happy life.  But this problem affects a lot 
of people on Mac/Win/Linux using ATI/Intel/nvidia, so it seems to be 
more than a driver issue and, most importantly, driver updates just 
aren't available for everyone.  So I choose to shorten my happy life 
running my bug riddled drivers.  It's time I saw a shrink...

To summarise: Your changes don't work for me with GL2 and I'm confident 
they won't help others - it seems to be QPainter drawing to the 
QGLWidget that's the problem.  I changed QPixmap to QImage but the 
result was the same - GL2 not working.

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

On Tue, Jun 22, 2010 at 17:55, Peter Mousley <scr...@mo...>wrote:

>  On 23/06/2010 0:59, Peter Mousley wrote:
>
> On 23/06/2010 0:34, Fabien Chéreau wrote:
>
>
> On Tue, Jun 22, 2010 at 16:28, Peter Mousley <scr...@mo...>wrote:
>
>> On 22/06/2010 20:16, Fabien Chéreau wrote:
>>
>>> Before deciding whether to merge or not in trunk, I would really like to
>>> see an alternative Qt based solution, not involving win32 API. I just played
>>> a bit with the QImage/QPixmap idea, and it works more or less, although it's
>>> a bit slow. See the attached 10 lines patch.
>>>
>>> Fabien
>>>
>>>
>>  Attached is an alternative that is much closer to working.  The two main
>> issues are:
>>
>>  Good! That should even be faster, by bypassing the QPainter stuff.
>
>
>> 1/ star labels only show correctly when a cluster/nebula is selected (need
>> the pulsing selection box)
>>  - planet labels, grid labels, etc., are fine
>>  - star labels are actually there, but they're black boxes
>>
>>
> try to glEnable(GL_BLEND)
>
> I had expected it was already set (which, upon checking, it is), so hadn't
> bothered with it.  Added it anyway - makes no difference.  I've also noticed
> that the star labels disappear when constellation art is on, but the planet
> labels are still okay.  What's different between planet and star labels?
> (I'm guessing there must be some GL state different? But what?)
>
>
>
>> 2/ text is not rotated (grid labels for example)
>>  - is this a limitation of bitmap images?
>>
>>
>
> glDrawPixel doesn't use the matrix. Try to draw the texture using a real gl
> call.
>
>
> As an infamous politician here once said, "Please explain!"
>
>
>  Thanks a lot! If you make taht working you'll be a hero for ATI users ;)
>
>
>  I've been delaying purchase of a new laptop because the one I want only
> comes with ATI.  Hadn't really thought that Stellarium may not work, but I
> need a replacement soon - need to get this bug fixed!
>
> I'll look at it again in the morning.
>
> Peter
>
>
> Problem 1 solved!  I added code to output if 42 GL capabilities were
> enabled or not, for both a star and a planet (just for some amusement, see
> attached).  Two were different; GL_BLEND and GL_TEXTURE_2D were both enabled
> for stars but not for planets.  Disabling GL_BLEND did not help, but
> disabling GL_TEXTURE fixed it.  Star labels now work properly with both
> OpenGL1 and OpenGL2  :-D
> As a bonus, the frame rate is up: (20 FPS using QPainter::drawImage; 30 FPS
> with GL_TEXTURE_2D enabled; and almost 40 FPS now (with GL_BLEND disabled,
> which still looks pretty good, FPS is above 40).  As a comparison, using
> QPainter::drawText direct to QGLWidget gives just under 60 FPS - when it's
> working.
>
> Now I just need rotated text.  Fabien?  Anyone else?
>
>
glDrawPixel just copy a buffer of pixel to the gl buffer, it doesn't take
into account the transformation matrix, so you cannot rotate or scale it. I
also already noticed that it's very slow for some drivers.
Instead you should create a new GL texture from the QPixmap ( with
QGlWidget::bindTexture() ) and display it using something similar to
Stelpainter::drawRect2d with added rotation feature.

Fabien


>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
>

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 25/06/2010 2:25, Peter Mousley wrote:
> I've changed to using textures for the labels and it looks good.  As a
> bonus, FPS is 15-20% higher than the 0.10.5 release when lots of labels
> are visible; it even works well with grid lines on.
>
> There is some cleaning up to do and it could be better integrated into
> StelPainter (for example, all code is lumped together for easy editing
> at the moment).  However, I believe this is ready for others to test and
> it's not worth spending extra effort at this time.  For testing now, I'm
> not so interested in "the text is upside down", etc.  I mainly want to
> hear from people with existing font corruption problems: Does the text
> look good?  Can you read it now?  (Note: If you're forcing OpenGL1,
> please also test with OpenGL2.)  For those without existing problems,
> does it work for you?  Are the frame rates high?
>
> Bzr branch is available at:
>       lp:~scrupeus/stellarium/fix-fonts-gltex
>
> Fabien/Bogdan - If this is considered okay for testing, could someone
> post a binary patch?  If you don't want to do that, I can host myself
> (Windows and possibly Linux - not Mac).  Either way, once a patch is
> available, I'll chase up everyone who posted a font-related bug report
> and get them to test it.
>
> Fingers crossed.
>
> Peter
>    

Anyone?

Re: [Stellarium-pubdevel] Font corruption workaround

[Fabien C. <fab...@go...>]

Hi Peter,
Sorry for the delay (I'm back from a long WE in Irland), i just had a
look at the code, which I like in general, but I have a couple of
comments:
 - You should try to use the QCache class
(http://doc.qt.nokia.com/4.6/qcache.html) for managing the texture
cache instead of reimplementing similar features in StringTextureList.
 - You should avoid all gl calls which are not compatible with
opengl3, i.e. glBegin/glEnd, and glTranslate/glRotate, instead try to
use vertex arrays, and to compute the rotation in the code itself.
 - Try to use QGLContext methods for creating/binding/deleting
textures. In StelPainter you have access to the QGLContext using the
static member StelPainter::glContext.

All those comment are implementation details and I generally agree
with the concept :)
Fabien

On Wed, Jun 30, 2010 at 13:44, Peter Mousley <scr...@mo...> wrote:
> On 25/06/2010 2:25, Peter Mousley wrote:
>> I've changed to using textures for the labels and it looks good.  As a
>> bonus, FPS is 15-20% higher than the 0.10.5 release when lots of labels
>> are visible; it even works well with grid lines on.
>>
>> There is some cleaning up to do and it could be better integrated into
>> StelPainter (for example, all code is lumped together for easy editing
>> at the moment).  However, I believe this is ready for others to test and
>> it's not worth spending extra effort at this time.  For testing now, I'm
>> not so interested in "the text is upside down", etc.  I mainly want to
>> hear from people with existing font corruption problems: Does the text
>> look good?  Can you read it now?  (Note: If you're forcing OpenGL1,
>> please also test with OpenGL2.)  For those without existing problems,
>> does it work for you?  Are the frame rates high?
>>
>> Bzr branch is available at:
>>       lp:~scrupeus/stellarium/fix-fonts-gltex
>>
>> Fabien/Bogdan - If this is considered okay for testing, could someone
>> post a binary patch?  If you don't want to do that, I can host myself
>> (Windows and possibly Linux - not Mac).  Either way, once a patch is
>> available, I'll chase up everyone who posted a font-related bug report
>> and get them to test it.
>>
>> Fingers crossed.
>>
>> Peter
>>
>
> Anyone?
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 1/07/2010 8:04, Barry Gerdes wrote:
> Hi Peter
>
> I tried your patch and did not notice any difference with the text 
> except that the fps was about 25% faster. But then I never had any 
> problems with the text in the first place.
>
> However on exiting the program I got the crash error message that has 
> cropped up a few times on past builds.
>
>
> Barry Gerdes
> Beaumont Hills Observatory
> S 33' 41' 44"    E 150' 56' 32"
>
Thanks Barry.  It's important for people without font problems to test 
this solution so as an informed decision can be made about making it the 
default code for everyone or just a workaround for those with problems.  
Your fps boost is even higher than what I get, although I think I'm 
being limited by the monitor refresh rate (60 Hz).

Re the crash, do you get it every time or just occasionally?  I found a 
similar bug and know where it's coming from (nothing to do with this 
patch), but I haven't posted it yet - better do so!

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Bogdan M. <dag...@gm...>]

On Mon, Jun 21, 2010 at 7:17 PM, Fabien Chéreau
<fab...@go...> wrote:
> Hi thanks for the effort! This is quite similar to the previous code we had
> in Stellarium, but we had to change to support international characters. I
> think you code suffers from the same problems that our had. Namely, if you
> want to display e.g. a chinese character, you need to use a font which
> supports it, otherwise you end up with a broken character. Qt solves this by
> reverting to other fonts if it sees that it's not supported by the base
> font. Also your code won't handle characters's linking, like in arabic.
>
> Actually there is also another quite easy way to fix the problem: render the
> text in a QImage or QPixmap and just dump the image on the screen. This is
> is probably easier than your solution, and could even also allow
> performances improvement by using caching of the whole words. I never did it
> so far because I always hoped that Qt will fix the problem, but now it
> indeed seems that they lack motivation for working on that..
> Fabien
>

An user commented elsewhere that switching the the Angle Measure on
and off solved one of the font problems. If necessary, I can dig up
the link.

Someone else reported that hovering the mouse over the bottom toolbar
and then selecting a star fixes the "unreadable description" problem.
Again, I can dig up the link if necessary.

On my netbook, the text is sometimes "scrambled" the first time
Stellarium is run and fixes itself on the consequent runs.

I think that the issue may be some kind of OpenGL
initialization/deinitialization problem with flags and/or buffers.

I'm sorry that I'm not participating very much in the mailing list
recently, but I will be quite busy in meatspace for the next two
weeks.

Regards,
Bogdan Marinov

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 3:07, Bogdan Marinov wrote:
> An user commented elsewhere that switching the the Angle Measure on
> and off solved one of the font problems. If necessary, I can dig up
> the link.
>
> Someone else reported that hovering the mouse over the bottom toolbar
> and then selecting a star fixes the "unreadable description" problem.
> Again, I can dig up the link if necessary.
>
> On my netbook, the text is sometimes "scrambled" the first time
> Stellarium is run and fixes itself on the consequent runs.
>
> I think that the issue may be some kind of OpenGL
> initialization/deinitialization problem with flags and/or buffers.
>
> I'm sorry that I'm not participating very much in the mailing list
> recently, but I will be quite busy in meatspace for the next two
> weeks.
>
> Regards,
> Bogdan Marinov
>
>    

I reported one of those 'fixes' (hovering over the toolbar), but while 
somewhat helpful for finding the cause, they're not a solution.

On my machine, text is often okay at start up, but then totally corrupts 
after a few seconds.  Very frustrating.

Re: [Stellarium-pubdevel] Font corruption workaround

[Peter M. <scr...@mo...>]

On 22/06/2010 20:16, Fabien Chéreau wrote:
> Before deciding whether to merge or not in trunk, I would really like 
> to see an alternative Qt based solution, not involving win32 API. I 
> just played a bit with the QImage/QPixmap idea, and it works more or 
> less, although it's a bit slow. See the attached 10 lines patch.
>
> Fabien
>

When you said "it's a bit slow", I thought, "oh, probably drops a couple 
FPS."  Two minutes later, I still didn't have any text, no toolbar, no 
infobar, no dialogues...  Did have some stars though!

Switched to GL1 and it runs, but FPS is about 1/3 drawing directly.  I 
removed the class constructions out of the last two lines (why are they 
needed?) and got about 2 FPS improvement (yawn...).  Note: You also need 
to move the text up by rect.y() in drawPixmap to put the text just off 
the top-right of the object.  Here's what I used:
         painter.drawText(-rect.x(), -rect.y(), str);
         qPainter->drawPixmap(0, rect.y(), tmp);

I don't think it's worth sending out at this stage - FPS is low and GL2 
doesn't work for me, so probably won't for others.  (Keep in mind I'm 
running a deliberately botched system to test these problems, but it 
seems to match what others get - I'm sure it would run with GL2 if I got 
my system back to normal.)

Peter

Re: [Stellarium-pubdevel] Font corruption workaround

[Barry G. <bar...@ho...>]

Hi Peter

 

I tried your patch and did not notice any difference with the text except that the fps was about 25% faster. But then I never had any problems with the text in the first place.

 

However on exiting the program I got the crash error message that has cropped up a few times on past builds.



Barry Gerdes
Beaumont Hills Observatory
S 33' 41' 44"    E 150' 56' 32"


 

> Date: Wed, 30 Jun 2010 21:44:29 +1000
> From: scr...@mo...
> To: ste...@li...
> Subject: Re: [Stellarium-pubdevel] Font corruption workaround
> 
> On 25/06/2010 2:25, Peter Mousley wrote:
> > I've changed to using textures for the labels and it looks good. As a
> > bonus, FPS is 15-20% higher than the 0.10.5 release when lots of labels
> > are visible; it even works well with grid lines on.
> >
> > There is some cleaning up to do and it could be better integrated into
> > StelPainter (for example, all code is lumped together for easy editing
> > at the moment). However, I believe this is ready for others to test and
> > it's not worth spending extra effort at this time. For testing now, I'm
> > not so interested in "the text is upside down", etc. I mainly want to
> > hear from people with existing font corruption problems: Does the text
> > look good? Can you read it now? (Note: If you're forcing OpenGL1,
> > please also test with OpenGL2.) For those without existing problems,
> > does it work for you? Are the frame rates high?
> >
> > Bzr branch is available at:
> > lp:~scrupeus/stellarium/fix-fonts-gltex
> >
> > Fabien/Bogdan - If this is considered okay for testing, could someone
> > post a binary patch? If you don't want to do that, I can host myself
> > (Windows and possibly Linux - not Mac). Either way, once a patch is
> > available, I'll chase up everyone who posted a font-related bug report
> > and get them to test it.
> >
> > Fingers crossed.
> >
> > Peter
> > 
> 
> Anyone?
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
 		 	   		  
_________________________________________________________________
New, Used, Demo, Dealer or Private? Find it at CarPoint.com.au
http://clk.atdmt.com/NMN/go/206222968/direct/01/

Re: [Stellarium-pubdevel] Font corruption workaround

[Barry G. <bar...@ho...>]

Hi Peter

 

I checked the FPS 4 times using similar builds of 4710 and got 30.5 fps max with 4710 and 39.5 fps max with your build. Repeatable results.

 

The crash happens every time. The most common reason originally was failing on downloads of satellite data.



Barry Gerdes
Beaumont Hills Observatory
S 33' 41' 44"    E 150' 56' 32"


 



Date: Thu, 1 Jul 2010 09:41:45 +1000
From: scr...@mo...
To: ste...@li...
Subject: Re: [Stellarium-pubdevel] Font corruption workaround

On 1/07/2010 8:04, Barry Gerdes wrote: 


Hi Peter
 
I tried your patch and did not notice any difference with the text except that the fps was about 25% faster. But then I never had any problems with the text in the first place.
 
However on exiting the program I got the crash error message that has cropped up a few times on past builds.



Barry Gerdes
Beaumont Hills Observatory
S 33' 41' 44"    E 150' 56' 32"
Thanks Barry.  It's important for people without font problems to test this solution so as an informed decision can be made about making it the default code for everyone or just a workaround for those with problems.  Your fps boost is even higher than what I get, although I think I'm being limited by the monitor refresh rate (60 Hz).

Re the crash, do you get it every time or just occasionally?  I found a similar bug and know where it's coming from (nothing to do with this patch), but I haven't posted it yet - better do so!

Peter
 		 	   		  
_________________________________________________________________
Need a new place to live? Find it on Domain.com.au
http://clk.atdmt.com/NMN/go/157631292/direct/01/