Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Oct 2012
Offline Last Active Sep 11 2014 07:25 AM

Topics I've Started

Rendering large meshes in OpenGl

10 September 2014 - 09:32 AM



I am rendering large meshes in a very simple and straightforward way (i.e. using VBOs), but as soon as meshes start having more than 0.5 mio triangles, rendering gets slower and scene manipulation is not fluid anymore.


When I look at some other applications (i.e. visualization applications), they can handle the same imported meshes in a much faster and more fluid manner. So my question is: how do they do it?


I am not using any shaders, but the speed difference between my application and the others is too large that it could only be a matter of shaders. My code basically resumes to:






Am I missing an important part of the puzzle?



My sockets are as fast as pipes..

14 April 2014 - 12:47 PM



For an IPC I used sockets for a long time. That's convenient and relatively fast.

Then I thought, at least when the 2 processes are on the same machine, that I could gain speed by using pipes instead. My idea of pipes was that they were using shared memory. But it turns out that my pipe communication is as slow as my socket communication. How can that be? Am I doing something wrong?


Currently, I have implemented the pipes on Windows, but if I can obtain a speed increase, I also want to do this on Linux.


Here my pipe implementation, client side:

// connect to an existing pipe:
HANDLE pipe=CreateFile("\\\\.\\Pipe\\myPipe",GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,0,0);

// Write something:
DWORD bytesWritten;

// Read something:
DWORD bytesRead;

And here my pipe implementation, server side:

// Create the pipe:

// Connect to client:

// Read and write from client is implemented in the same was as for the client read/write routines

Anything I am doing wrong?

Function addresses are not fixed relative to each other?

14 July 2013 - 01:19 PM



while trying to find out the reasons of a strange behaviour of my library, I stumbled upon this:


cpp file 1 of library:

void printRelativeFunctionAddresses()
    printf("printRelativeFunctionAddresses-giveMeAOne: %i\n",int(printRelativeFunctionAddresses)-int(giveMeAOne));
    printf("printRelativeFunctionAddresses-giveMeATwo: %i\n",int(printRelativeFunctionAddresses)-int(giveMeATwo));

Cpp file 2 of library:

extern "C" __attribute__((visibility("default"))) int giveMeAOne()
extern "C" __attribute__((visibility("default"))) int giveMeATwo()

the function printRelativeFunctionAddresses prints the same value everytime I start the library from a specific client application A. But when I use a different client application B (but that loads the exact same library), then the output is different! How can that be? Are functions shifted around during the library load operation?


I am running the library on Ubuntu 32bit, using Qt5.1.0

Library function also used internally: segmentation fault on Linux

12 July 2013 - 09:07 AM



I am using Qt 5.1.0, but I guess this is not directly related to the use of Qt.


I have a library which in fact is my application. It exports many API functions. Some of those API functions are also called internally (from the library itself). That worked fine on Windows, Mac and Linux. But changing the compiler version on Linux, has caused problems. I have following API functions (example):

extern "C" __attribute__((visibility("default"))) int returnMeAZero()

extern "C" __attribute__((visibility("default"))) int returnMeAOne()

I have a client application that loads the library and dynamically binds above 2 functions with dlopen and dlsym. That client application (an executable), when started, calls "returnMeAZero" which works fine. Internally, the library sometimes calls "returnMeAOne" which works also fine. But when the library internally calls "returnMeAZero" it crashes with a segmentation fault.


Above example is simplified. There are several hundreds of functions similar to those above. And only those that are references in the client source code cannot be called internally by the library. That seems very strange to me. Is there any logical explanation for that behaviour?


Mutex creation in multithreaded library

30 May 2013 - 10:26 AM



I think I have a kind of chicken-egg problem:


I have a library (dll) that is pure C and that is supposed to be thread-safe.

How do I initialize it? I mean, at some point I need to call


do some other initializations here

The above section of code should be run only the very first time someone calls a function in the library. But what if several threads call the library at the same time? Best would be to have a mutex to make sure the initialization happens only once, but mutexes need to be initialized...

Any idea?