Strange problem after OS migration

Hi all,
I used to work with fedora 8, but recently I installed fedora 10.
In the new environment I found some strange problem in my qt based OCC application (please note that it seems to me that only my OCC application is affected)
Problem 1: Prs3d_Text::Draw doesn't display anything (no more text on the viewer)
Problem 2: In neutral context I can rotate, move, zoom, but if a I open a local context and I add some AIS objects any operation (rotate, move, zoom) is extremely slow

The source code of the application is the same in both environment, the differences are:
Fedora 8 - Qt 4.3.3 - NVIDIA driver 100.14
Fedora 10 - Qt 4.4.3 - NVIDIA driver 180.44

Any suggestion?

Marco Matt's picture

The problem persist using Qt 4.3.3 on Fedora 10.
So I think it is a problem with the new Xorg or the new NVIDIA driver.
Unfortunately the old NVIDIA driver doesn't install on my new Fedora 10

Marco Matt's picture

The problem is not related to NVIDIA driver. With Fedora 8 and NVIDIA driver 180.44 I can see my text in the viewer.
So the only difference is the Xorg server, but as I know OpenCASCADE use OpenGL directly to draw in the viewer window, so the X version should not affect any behaviour.
Any suggestion on how to investigate the problem is really appreciated.

Paul Jimenez's picture

You may want to check if the NVIDIA driver is correctly installed to accelerate OpenGL. Not long ago I tested Mesa3D on Windows with an OCC program that shows the trihedron with the ZBUFFER option, and the text was messy (almost invisible). Linux uses Mesa3D by default. Maybe that is the reason.

I haven't used OCC in Linux, so it's just a blind assumption.

Marco Matt's picture

Thank Paul, but it was one of my first test.

In any case I sweated blood, but I solved the problem.

OpenCASCADE (or a library it depends on) doesn't use fontconfig to access fonts and on Fedora 10 the legacy X11 fonts aren't installed by default any more.
After installing old X11 legacy fonts my app works well.

The (very) strange thing is that without the fonts the viewer was very slow (but only when "missing" text was present); my hypothesis is that during the viewer update it spents a lot of time searching for the missing fonts.