[Clam-devel] Re: [Issue N182839] Competing Text Renderers

David García Garzón dgarcia at iua.upf.edu
Mon Oct 15 08:29:44 PDT 2007


On Friday 12 October 2007 18:04:06 qt-bugs at trolltech.com wrote:
> Hi David,
>
> On Thursday, 11. Oct 2007 02:28 David García Garzón wrote:
> > I was commenting this bug with support crew at Redwood City.
> >
> > I am attaching a minimal example that reproduces the following two
> > seamingly related bugs in my laptop:
> >
> > One single QGlWidget using renderText blocks for a short time (10s)
> > until it outputs the following message and then all works:
> > 	QOpenGLPaintEngine: Failed to create fragment programs.
> >
> > My interpretation: It tries for so long to create a fragment program
> > for the font rendering and it holds until it realizes that it is not
> > available in my hw, then a fallback method is used.
> >
> > Two QGlWidgets on the same window get blocked apparently on the same
> > point but now on every repaint instead than just on the first paint
> > and they block alternatively.
> >
> > My interpretation: It seems that there is a missmatch on the state of
> > the fragment program tried, and the actual data that can be shared
> > among opengl widgets.
>
> This seems to work fine here, but then again my hardware does support
> fragment programs. What OS, Qt version and graphics hardware are you
> using?
>
> Thanks.

I talked with Jason Barron who asked me to send the bug report, but I took 
those details for granted. Sorry for that. 

I am using Qt 4.3.2, the one in Ubuntu Gutsy. Like you, I cannot reproduce the 
bug on most cards having proper fragment program support on Linux. But the 
bug reproduced in several environments where the program was working with Qt 
4.2.X, for example my laptop having an integrated Intel (driver i810), or the 
destop computer in my previous office having an ATI Radeon 220 Xpress. Also 
some of our users have complained, i could ask them for their hardware. I 
think you could fall back to the mesa driver to try that by changing the X 
driver to an standard non-accelerated.

Looking at the code, it has specific logic for the case not having fragment 
programs support. But as it was a hardware dependant path maybe it was not as 
fully tested as it should.

I would like to add some traces on qt and test it in my hardware. Do you have 
any recommended procedure to test Qt without interfering with the standard 
installation?

David.





More information about the clam-devel mailing list