Category: OpenGL

Random thoughts about a11y on clutter

Clutter and a11y support are important issues related with Gnome, so it is normal that sometimes the question “a11y and Clutter” arise. Some time ago this appears on the desktop devel list, and Emmanuel Bassi closes says that there are a plan for it in the future [1]

And now, this topic has return, this time on the clutter mailing list [2] [3]

Some time ago I was playing with this two topics, and I made some coding tests too. As this codings tests are still too basic, here [4] is a link to a pdf with my first thoughts after this implementation, so anyone could read about it if he wants.

Reviving GLSL

The other day, looking at planet Gnome, I found one more interesting that the others. This was writen by MDK, and its titled Vector drawing: OpenGL shaders and cairo.

This post continues, in some way, a post written by Tim Janick on his blog, about OpenGL for Gdk/Gtk+, that summarizes some of problems about using OpenGL with Gdk/Gtk+.

MDK made some tests to compare one an another, I had a little curiosity and check the code. The shader version was written in Cg, and as there are a lot of time that I doesn’t write nothing related to shaders, I decided to waste the little free time I have making the GLSL version of this test this afternoon.

I same the sames tests, except by environment:

  • AMD 1800+ 784MB RAM
  • Geforce 5900FX 128 MB RAM
  • modified source code (you’ll dont require Cg Toolkit, instead you’ll require Glew)

And the visual results:


Cairo bezier


Cg bezier

GLSL bezier

But the most curious was about the times (sorry, not chart this time);

  • cairo: 0,18494 s
  • cg: 0.01927 s
  • GLSL: 0.00155 s

GLSL better than cg? I suppose that this is the easy answer but:

  • First at all: its too much difference, it has no sense
  • AFAIK GLSL driver compiler its almost the Cg compiler (they use a Unified Arquitecture), you only need to see the extension EXT_Cg_Shader (use Cg code to define a shader object)
  • OpenGL works asynchronously
  • The profile: Cg implementation uses a concrete profile (CG_PROFILE_ARBVP1), GLSL hasn’t got this concept, it tries allways to search the bext vertex/fragment program extension to use.
  • So: the time of only draw some curves its not a accurate (we knowed it before) measure, it is only a guide

Conclusion: it is good to revive some time GLSL, I need to do this more often, thanks to MDK to give us some code to play !

NVPerfKit 2.1 supports linux

When you are debugging a graphical aplication, using OpenGL, debugging is very complex. You can’t use the common debuggers, as gdb, because the graphical part are executed at the “server side”, at the card, therefore, managed by the OpenGL drivers, asynchronously with respect your program.

But, as in other programs, debugging and profiling a very important part of the development process, more important with the pass of the time, as the graphical cards are more and more complex, and make more and more work, not only graphical. For example, Havok creates and physical effects engine implemented over the graphics card, called Havok FX.

Recently, NVIDIA released NVPerfKit 2.1, a package of performance tools to help debug and profile Direct3D and OpenGL aplications, that for the first time supports Linux!! Its a good new. It isn’t free, and includes gDEbugger as a 30-day-trial version, but, well this is better than nothing 😐

When I was developing my Master Thesis (Proyecto de Fin de Carrera), I missed a lot some kind of tool to debug and test perform of my program, but, or this tools wasn’t released or my card doesn’t support it … so I need to use the “universal flag-method” 😉 to debug the aplication, and use and ad-hoc system to profile it. But well, at this moment there are some NVPerfkit tools that don’t support my card (well really, my card don’t support this tools, for example, don’t support GPU counters 🙁 ), so I would need to do that anyway.

Someday I will write a post about this project. I hope to someday I will get that this compile at linux, and migrate my “Hair Editor” to GTK, but “when I have some time” ….

A 3D view for baobab widget

Meanwhile some igalians (*) was making a very useful view of the baobab, I was spending my time creating a 3D of this widget. To do that I used the great library gtkglext , which allows to add OpenGL drawing to any widget gtk.

While the base 2D view are very intuitive, and allow you a visual track to your directorioes, with tooltips, etc, my 3D view is a very beatiful 🙂 view of a widget, but it is almost useless, as is hard to manage and select the directories. But, as I’d said, this look greats, and its funny create this, although I became a leech of the igalians laptops. For example, the Mario’s one, forcing him to work in this widget, when I kidnapped his laptop … 😉

At the end of the post you can see a screenshoot of an alpha release of this widget. The next step is create the blocks more consistently, as at this moment has some visual “leaks”, and integrate with the original base.

This is a headache problem, as to avoid to add a new dependence with the baobab, I was working in a “parallel experimental” branch. “One day” its possible a total integration, but for this moment, we have two work groups.
3D view of Baobab!!

[*] :: Alex, Miguel, Mario, Henrique