texus.github.io

Finding physical screen size from HMONITOR using EDID

Sat, 30 Nov 2019 10:01:00 +0000

It turns out that getting the physical size of a monitor (centimeter or inches instead of pixels) isn’t that simple. There are several ways to get the size but not all of them are reliable. Finding out which size belongs to which monitor is also not so easy. In this blog post I will provide a way to find the physical size of a monitor in millimeters and a way to match this to a given HMONITOR.

Although I will provide a full solution with comments, I will not discuss the different ways that exists to get the screen sizes. For this you can read this blog post, which together with its update, provided me with most of the information required to fulfil my task. To match the HMONITOR and HDEVINFO, I however took a different approach. Instead of a partial match between two strings, I found a device id that is identical in both parts of the code, except for the case (one string is a lowercase version).

Disclaimer: although this code has been tested on multiple computers with multiple types of monitors, I do not guarantee that the code will work for all cases.

In order to find the screen sizes, we will use the SetupAPI to extract the EDID block from the registry. Every digital monitor is supposed to provide this EDID and I haven’t personally encountered a monitor where the size can’t be found using this method. It may however be a good idea to provide an alternative in case there is no EDID, the EDID can’t be accessed or if matching the id with HMONITOR ends up not working.

The following helper function will extract the width and height in millimeter for all monitors. It returns the size for each device id.

// This function may return more monitors than actually connected to the computer, these will
// be filtered out later when matching the device ids.
typedef std::map<std::wstring, std::pair<int, int> > PhyMonitorSizes; // DeviceId -> (width, height)
PhyMonitorSizes findMonitorSizesFromEDID()
{
    PhyMonitorSizes screenSizes;

    const GUID GUID_DEVINTERFACE_MONITOR = { 0xe6f07b5f, 0xee97, 0x4a90, 0xb0, 0x76, 0x33, 0xf5, 0x7b, 0xf4, 0xea, 0xa7 };
    const HDEVINFO hDevInfo = SetupDiGetClassDevs(&GUID_DEVINTERFACE_MONITOR, NULL, NULL, DIGCF_DEVICEINTERFACE);

    // Instead of creating a buffer in each iteration and calling SetupDiGetDeviceInterfaceDetail twice (once to find the required
    // buffer size and once to actually get the data), we create a buffer up front with the maximum size it can have.
    // The device id that we will match with can be at most 128 characters, so the id can't be any larger here (or we have issues).
    // Note that the buffer is slightly larger than it has to be (as "sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA)"
    // was used instead of "offsetof(SP_DEVICE_INTERFACE_DETAIL_DATA, DevicePath)").
    wchar_t devPathBuffer[sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_W) + (128 * sizeof(wchar_t))];

    // Loop over the device interfaces using the SetupAPI
    DWORD monitorIndex = 0;
    SP_DEVICE_INTERFACE_DATA devInfo;
    devInfo.cbSize = sizeof(devInfo);
    while (SetupDiEnumDeviceInterfaces(hDevInfo, NULL, &GUID_DEVINTERFACE_MONITOR, monitorIndex, &devInfo))
    {
        ++monitorIndex;

        // Retrieve the id of the device interface
        SP_DEVICE_INTERFACE_DETAIL_DATA_W* devPathData = (SP_DEVICE_INTERFACE_DETAIL_DATA_W*)devPathBuffer;
        devPathData->cbSize = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA_W);
        SP_DEVINFO_DATA devInfoData;
        memset(&devInfoData, 0, sizeof(devInfoData));
        devInfoData.cbSize = sizeof(devInfoData);
        if (!SetupDiGetDeviceInterfaceDetailW(hDevInfo, &devInfo, devPathData, sizeof(devPathBuffer), NULL, &devInfoData))
            continue; // Error

        // The device id that we found here will be used to match with the HMONITOR later
        const std::wstring deviceId = devPathData->DevicePath;

        // Find the instance id of the device to look up the EDID in the registry
        wchar_t instanceId[MAX_DEVICE_ID_LEN];
        if (!SetupDiGetDeviceInstanceIdW(hDevInfo, &devInfoData, instanceId, MAX_PATH, NULL))
            continue; // Error

        // Find the EDID registry key
        HKEY hEDIDRegKey = SetupDiOpenDevRegKey(hDevInfo, &devInfoData, DICS_FLAG_GLOBAL, 0, DIREG_DEV, KEY_READ);
        if (!hEDIDRegKey || (hEDIDRegKey == INVALID_HANDLE_VALUE))
            continue; // Error

        // Read the EDID data from the registry
        BYTE dataEDID[1024];
        DWORD sizeOfDataEDID = sizeof(dataEDID);
        if (ERROR_SUCCESS == RegQueryValueExW(hEDIDRegKey, L"EDID", NULL, NULL, dataEDID, &sizeOfDataEDID))
        {
            // Extract the width and height of the monitor from the EDID
            int WidthMm = ((dataEDID[68] & 0xF0) << 4) + dataEDID[66];
            int HeightMm = ((dataEDID[68] & 0x0F) << 8) + dataEDID[67];
            screenSizes[deviceId] = std::make_pair(WidthMm, HeightMm);
        }

        RegCloseKey(hEDIDRegKey);
    }

    return screenSizes;
}

Getting the same device id from the HMONITOR also requires quite some work. The first step is to call GetMonitorInfo and get the szDevice member from MONITORINFOEX, but this only gets us halfway. The device name returned by GetMonitorInfo isn’t the same as the device id that we got with the SetupAPI, so we will define another helper function that finds a mapping between these device names and ids.

typedef std::map<std::wstring, std::wstring> DevNameToDevId; // DeviceName -> DeviceId
DevNameToDevId getDeviceNamesToIdMap()
{
    DevNameToDevId namesToIdMap;

    // Query how many display paths there are
    UINT32 nrPaths;
    UINT32 nrModes;
    GetDisplayConfigBufferSizes(QDC_ONLY_ACTIVE_PATHS, &nrPaths, &nrModes);

    // Retrieve the active display paths.
    // Although we don't need the modes, documentation of QueryDisplayConfig says we can't use NULL for them.
    std::vector<DISPLAYCONFIG_PATH_INFO> paths(nrPaths);
    std::vector<DISPLAYCONFIG_MODE_INFO> modes(nrModes);
    QueryDisplayConfig(QDC_ONLY_ACTIVE_PATHS, &nrPaths, &paths[0], &nrModes, &modes[0], NULL);

    // Loop over the display paths and map the device name to the unique id that we will use
    for (unsigned int i = 0; i < paths.size(); ++i)
    {
        DISPLAYCONFIG_SOURCE_DEVICE_NAME sourceName;
        sourceName.header.type = DISPLAYCONFIG_DEVICE_INFO_GET_SOURCE_NAME;
        sourceName.header.size = sizeof(sourceName);
        sourceName.header.adapterId = paths[i].sourceInfo.adapterId;
        sourceName.header.id = paths[i].sourceInfo.id;
        DisplayConfigGetDeviceInfo(&sourceName.header);

        DISPLAYCONFIG_TARGET_DEVICE_NAME targetName;
        targetName.header.type = DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME;
        targetName.header.size = sizeof(targetName);
        targetName.header.adapterId = paths[i].sourceInfo.adapterId;
        targetName.header.id = paths[i].targetInfo.id;
        DisplayConfigGetDeviceInfo(&targetName.header);

        namesToIdMap[sourceName.viewGdiDeviceName] = targetName.monitorDevicePath;
    }

    return namesToIdMap;
}

Now it is time to put the pieces together. We get the device name from the HMONITOR, we look it up in the map returned by getDeviceNamesToIdMap to get the device id, we look that up in the map from ‘findMonitorSizesFromEDID’ and then we are done. The only remaining caveat is that the device id that comes from SetupDiGetDeviceInterfaceDetail seems to be a lowercase version of the id that we got via DisplayConfigGetDeviceInfo, so we must compare the strings as case-insensitive.

std::pair<int, int> getMonitorSizeInMillimeter(HMONITOR hMonitor)
{
    const PhyMonitorSizes& sizesById = findMonitorSizesFromEDID();
    const DevNameToDevId& deviceIdsByName = getDeviceNamesToIdMap();

    // Find the device name from the HMONITOR
    MONITORINFOEXW monInfo;
    monInfo.cbSize = sizeof(monInfo);
    if (!GetMonitorInfoW(hMonitor, &monInfo))
        return {}; // Error

    // Find the device id belonging to that name
    auto deviceIdIt = deviceIdsByName.find(monInfo.szDevice);
    if (deviceIdIt == deviceIdsByName.end())
        return {}; // Error

    const std::wstring& deviceId = deviceIdIt->second;

    // We now need to loop over the data returned from FindMonitorSizesFromEDID and do a case-insensitive comparison because
    // the device id from FindMonitorSizesFromEDID seems to be in lowercase.
    for (auto it = sizesById.begin(); it != sizesById.end(); ++it)
    {
        const std::wstring& devId = it->first;
        const std::pair<int, int>& size = it->second;
        if (!caseInsensitiveComparison(deviceId, devId))
            continue;

        // We matched the device id from the HMONITOR with the one from SetupAPI, so we now have its size.
        // Keep in mind that the size is independent of the orientation of the monitor. You may still want
        // to add code that swaps the width and height in case the monitor is rotated (which could easily
        // be detected: if the monitor has a larger width in pixels then it must also have a larger width in mm).
        const int phyWidthMm = size.first;
        const int phyHeightMm = size.second;
        return std::make_pair(phyWidthMm, phyHeightMm);
    }

    // If we pass here then we didn't find a match and we couldn't get the size of this monitor
    return {};
}

I left out the implementation of caseInsensitiveComparison in this blog post, but the full code can be found in this gist.

Looking back at 5 years of TGUI

Sun, 12 Feb 2017 18:49:00 +0000

Today TGUI celebrates its 5th birthday. When it was originally released, I never thought it would get this far. I’m really happy to see that several people are using the library, which gets downloaded 3 times per day on average now. A lot has changed during these 5 years and I wanted to take the opportunity to look back at the evolution of the library.

The reason why I started this gui is a bit stupid actually. Five years ago I was still a noob in programming and when I wanted to write a game I just started writing the first thing that would be seen when the game started: the menu screen. I usually didn’t get much further than that. So I wrote some simple gui using the Windows API, DirectX and afterwards for SFML. The difference between them was that the one for SFML would end up containing a lot more than just buttons and text fields. I decided that unlike the earlier code that I kept for myself I would release this code because I couldn’t really find a gui library for sfml. Obviously SFGUI already existed but I somehow missed that it was already released. Looking back at the old posts I see that the current SFGUI topic was only created one month after I started TGUI and I must have missed that their old thread contained 11 pages and only looked at the first few posts in that thread where it was said that it wasn’t finished yet. If I had discovered SFML several months later I might have never published TGUI at all.

So after a few months of development, on 12 february 2012, I released TGUI 0.3 on the SFML forum (the original post no longer exists, it was edited later). The meaning of the “easy” part of the gui was mostly about the fact that I was a beginner programmer myself and the code thus wouldn’t have complicated stuff in it, something that is no longer true today. The library was still rapidly changing and patch releases arrived within days from each other. After a few months support for OS X and the first Form Builder were also added. The main issue of this version was that I didn’t know how to distribute it yet.

With 0.4 I started using git and cmake meaning that people could actually use this version without too many issues. The panel widget finally worked which made this the first version to have hierarchy in widgets. The version however still contained a lot of serious bugs. These days bugs are usually isolated and happen in specific cases, but back then you could have a crash just by creating a slider widget with the default theme and then moving your mouse.

When 0.5 was released at the end of 2012 I finally had a version that was worthy of being released. Many improvements were made and several widgets were added, including ChildWindow. When I started the gui library I told myself that the condition of having a 1.0 release was a working child window and I never expected to actually have one. But by the time 0.5 was released I still didn’t believe the library was ready to get a 1.0 release. Although I called it the first stable version back then, this is a title I believe should go to 0.6 instead as people trying to use 0.5 regulary encountered issues. There was one “big” game that tried using TGUI 0.5 but they eventually decided to rewrite their code and no longer use TGUI.

At the beginning of 2014, after a year of development, TGUI 0.6 was finally released. This is the version that I consider the first one to be stable. For two whole years this version has been getting patch releases, making it the version that has been the stable branch for the longest time. TGUI was finally getting used by a lot of people for small projects and I was seeing regular downloads. The major downside of this version is that, despite the fact that it was useful enough, it was lacking a lot of useful features. I tried using my own library once and I found that several things that I wanted to do were already in 0.7-dev but simply not possible in 0.6, so there was still a lot to improve.

The entire gui would go through yet another large rewrite. During these 2 years of patches in 0.6 I was of course working on the 0.7 version. Eventually 0.7-alpha would be released which contained tons of features that were lacking in earlier versions. This is also the version where experimental android and ios support were added. Unit tests were also introduced in this version as an attempt to find bugs earlier. TGUI 0.7 was supposed to become a version that was almost worthy of being called 1.0, but I realized that the planned changes would still take too long to implement. The downloads were about 50-50, half downloaded 0.6.10, the other half downloaded 0.7-alpha. Both options were not optimal. If you downloaded 0.6 then you were missing 2 years worth of features but if you would use 0.7-alpha then you would have to rewrite a lot of your code once I released 0.7-beta. So I made the decision to release 0.7-alpha as 0.7 and turn 0.7-beta into 0.8. This way people would stop downloading an outdated version and would have a version which receives compatible patch releases that doesn’t break their code. There was just one issue, there was a reason it was originally called alpha, it wasn’t finished yet. Although TGUI 0.7 is the best version so far, I dropped functionality by releasing it early, the main example being the form builder. TGUI has had a drag-and-drop form builder since 0.3.7 and now its gone. This why I’m still not satisfied with the current release, but this is an issue that I intent to fix with TGUI 0.8.

TGUI 0.8 will finish what was left broken in 0.7. The theme class and renderers will be improved, a much larger portion of the code will have unit tests and the Form Builder will be reintroduced. A .Net binding will also be available for those who want to work in C# instead of C++. TGUI 0.8 will basically be a version that is almost worthy of getting a 1.0 tag.

IEEE 802.15.4 Sniffer for OpenMote-CC2538

Sun, 24 Jul 2016 19:29:00 +0000

For my first research intership that is part of my Masters in Computer Science study I wrote a sniffer for IEEE 802.15.4 networks which is written to run on the OpenMote-CC2538 hardware.

Features:

The sniffer is lossless, all packets are captured
The captured packets can be monitored real-time in Wireshark (or can be written to a pcap file)
The sniffer is cross-platform, it will work on Windows, Linux and Mac OS X
You can either show the FCS or replace it with the RSSI, LQI and an FCS Valid bit
CRC checks and retransmissions are used on the serial connection to avoid possible corruption between the peripheral and host

For more information, check the README in the github repository.

Debugging on OpenMote-CC2538 with J-Link (using nemiver)

Mon, 25 Jan 2016 19:02:00 +0000

After trying for several days to get debugging working in Eclipse, I was told that it would be easier to use nemiver. I tried it and worked on the first try without any problems. This post will show the easy steps necessary to debug the code running on the OpenMote hardware.

My setup is the following: a linux pc (running Arch Linux), the SEGGER J-Link EDU, the OpenMote-CC2538 and the OpenBase to connect the mote to the pc. Also an ARM-JTAG-20-10 adaptor was used to connect the J-Link to the JTAG on the OpenBase.

The first thing to do is start the J-Link GDB Server which you can download from the SEGGER website. I am using V4.96f as I faced some problems introduced in V5.02b, but these issues should have already been fixed so the latest version should also work.

JLinkGDBServer -device CC2538SF53

The J-Link GDB server will be listening to new GDB connections on port 2331 by default.

In another terminal we can then start the GDB session, but how easy this is depends on whether you are using the OpenMote firmware or not to write your program.

Using the firmware

When your program is written with the OpenMote firmware you just have to execute the nemiver target in the Makefile. So after running “make” to build the program, running “make nemiver” will do everything for you: start the nemiver debugger, flash your program to the OpenMote and break at the beginning of your program.

Without the firmware

First create a file (name it e.g. cc2538_gdb.gdb) with the following contents:

target remote localhost:2331
monitor interface JTAG
monitor endian little
monitor speed auto
monitor flash device = CC2538SF53
monitor flash breakpoints = 1
monitor flash download = 1
monitor reset
load
break main
continue

Secondly we setup the GDB connection and upload your program to the J-Link GDB server. The command to run is the ARM GDB, the debugger for the ARM GCC compiler that you used to compile the binary. On Arch Linux this program is called arm-none-eabi-gdb but it may have a different name in other linux distributions (e.g. in Ubuntu the package is called gdb-arm-none-eabi). The parameter to the “--command” option is the file you just created and the “program.elf” is the binary that you should have build.

arm-none-eabi-gdb --batch --command=cc2538_gdb.gdb program.elf

Finally you can start nemiver and start debugging your program.

nemiver --remote=localhost:2331 --gdb-binary=/usr/bin/arm-none-eabi-gdb program.elf

Using parallel_for from Intel TBB

Tue, 17 Nov 2015 15:20:00 +0000

This post will show an example of the parallel_for function from the Intel TBB library. Every part of the code is well commented to explain what it does. Below the example you will find other explanations on how to improve the code and how to avoid the bad programming practices that were used in the example to keep it simple.

parallel_for example

#include <iostream>
#include <vector>

// Intel TBB has split the declaration of its classes and functions in different headers so that you only
// include the part you need. We need tbb::blocked_range and tbb::parallel_for in the code so we only need
// to include their corresponding headers.
#include <tbb/parallel_for.h>
#include <tbb/blocked_range.h>

// We have one global list on which we will do calculations. We immediately initialize the list with 10000 zeros.
std::vector<double> data(10000, 0);

// This function contains the code without parallelization.
// The function is not used, I just included it to show what the code will do.
// The algorithm will just increment all elements in the list by 1.
void algorithm_without_tbb()
{
    for (size_t i = 0; i < data.size(); ++i)
        data[i] += 1;
}

// This is the functor which Intel TBB will use inside the tbb::parallel_for function.
// A functor is just a struct/class with a call operator (operator()). Having this operator allows an object
// of this type to behave like a function. Using the call operator allows Intel TBB to work with both classes and functions.
struct IncrementElements
{
    // This function will be called inside tbb::parallel_for. What the range contains is entirely up to Intel TBB,
    // but you can expect it to be [0,9999] if you only use one thread (since there are 10000 elements).
    // If you use 2 threads then Intel TBB could call this function twice, once with [0,4999] and once with [5000,9999].
    void operator()(const tbb::blocked_range<size_t>& range) const
    {
        // Instead of looping over [0,9999] we loop over the range given by Intel TBB.
        // The first element can be retrieved with range.begin() and range.end() will return one after
        // the last element (so that you have to use < instead of <=).
        // The 'range' that we use here was the parameter of this function.
        for (size_t i = range.begin(); i < range.end(); ++i)
            data[i] += 1;
    }
};

int main()
{
    // We just execute all the code 5 times
    for (size_t t = 0; t < 5; ++t)
    {
        // Calling this function instead of running the code below results in the same result if
        // the parallel code is implemented correctly.
        //algorithm_without_tbb();

        // To use Intel TBB we first have to create a range object. This is not the same one as what Intel TBB passes
        // to the functor, but the ranges passed to the functor will always be subranges of this one. So
        // eventually all elements in this range will be processed by Intel TBB.
        // As we want to run the code on all elements in the list, which we usually want, the range is [0,9999]
        tbb::blocked_range<size_t> range(0, data.size());

        // We have to create a temporary instance of the functor class. The 'func' object will behave like
        // a function and by running func(...) which tbb::parallel_for does, the IncrementElements::operator()(...)
        // will be executed. I use 'auto' as type since you shouldn't bother about the exact type of the object.
        auto func = IncrementElements();

        // At this point, nothing has happened yet. By calling tbb::parallel_for, the code in the functor
        // will be executed (on several threads each with their own subrange) so that after this call all
        // elements in the list will have been incremented.
        tbb::parallel_for(range, func);
    }

    // Check to make sure that all elements in the list have been incremented 5 times
    for (size_t i = 0; i < data.size(); ++i)
    {
        if (data[i] != 5)
        {
            std::cout << "ERROR" << std::endl;
            return 1;
        }
    }

    std::cout << "SUCCESS" << std::endl;
    return 0;
}

Removing temporary variables

The ‘range’ and ‘func’ variables in the main function don’t have to be created explicitly, I only did it like that to explain each part separately. So the following lines from the code

tbb::blocked_range<size_t> range(0, data.size());
auto func = IncrementElements();
tbb::parallel_for(range, func);

can be written in one line:

tbb::parallel_for(tbb::blocked_range<size_t>(0, data.size()), IncrementElements());

Removing the global variable

Global variables are a very bad programming practice and they should be avoided where possible.

So let’s change the code so that we no longer rely on a global vector:

#include <iostream>
#include <vector>
#include <tbb/parallel_for.h>
#include <tbb/blocked_range.h>

// The global 'data' variable no longer exists in this example.
// The variable will instead be created inside the main function.

class IncrementElements
{
public:

    // Since there is no more global 'data' variable, the operator() will not be able to access the data (which has
    // been created in the main function). To solve this, the main function will pass a pointer to the data to
    // this class which we will copy in our private 'm_data' variable. We have to use a pointer or reference
    // instead of copying the vector because otherwise the original vector will never be changed.
    // The private 'm_data' member has to be a pointer since Intel TBB will internally copy this class a few times.
    IncrementElements(std::vector<double>* dataPtr)
    {
        m_data = dataPtr;
    }

    // It would of course have been easier if the vector could directly be passed as an argument to the
    // call operator, but since this function is called internally by Intel TBB we have no control over its
    // parameters and the vector should thus already be passed earlier, which is usually done in the constructor.
    void operator()(const tbb::blocked_range<size_t>& range) const
    {
        for (size_t i = range.begin(); i < range.end(); ++i)
            (*m_data)[i] += 1; // Note that we now have to use (*m_data)[i] instead of data[i]
    }

    // The 'm_data' variable could just as well be public but it is not needed outside this class
    // and it is better to keep it local instead of allowing other parts of the code to access it.
    // The variable will just hold a pointer to the 'data' vector that we create in the main function.
private:
    std::vector<double>* m_data;
};

int main()
{
    // The data variable is now created locally inside the main function.
    std::vector<double> data(10000, 0);

    for (size_t t = 0; t < 5; ++t)
    {
        // This time the functor gets a pointer to the data as parameter to its constructor.
        // Other than that the code does exactly the same.
        auto func = IncrementElements(&data);
        tbb::parallel_for(tbb::blocked_range<size_t>(0, data.size()), func);

        // The code above could again be written in a single line without the temporary 'func' variable:
        // tbb::parallel_for(tbb::blocked_range<size_t>(0, data.size()), IncrementElements(&data));
    }
}

Using the initializer list

I know that many beginning programmers don’t know how to use the initializer list so I just initialized the m_data variable inside the constructor itself. It is however a good habit to always use the initializer list when possible. There are even cases where you have to use it and can’t assign the value inside the constructor.

The constructor of the IncrementElements looks like this when we use the initializer list:

IncrementElements(std::vector<double>* dataPtr)
    : m_data(dataPtr)
{
}

Final code

When removing all comments we end up with this short example which you should now be able to understand:

#include <vector>
#include <tbb/parallel_for.h>
#include <tbb/blocked_range.h>

struct IncrementElements
{
    IncrementElements(std::vector<double>* dataPtr) :
        m_data{dataPtr}
    {
    }

    void operator()(const tbb::blocked_range<size_t>& range) const
    {
        for (size_t i = range.begin(); i < range.end(); ++i)
            (*m_data)[i] += 1;
    }

private:
    std::vector<double>* m_data;
};

int main()
{
    std::vector<double> data(10000, 0);
    for (size_t t = 0; t < 5; ++t)
        tbb::parallel_for(tbb::blocked_range<size_t>(0, data.size()), IncrementElements(&data));
}

More complex code

Although the example above is a very simple one, all code that just executes something on every element of a list has extremely similar code. The for loop that you have in your non-parallel version can almost literally be copied to the call operator of the functor, you just have to change the start and end of your for loop. After that just make sure that the operator has access to all needed variables and you are done.

CMake and Gcov

Sun, 06 Sep 2015 03:04:00 +0000

While trying to use Gcov for my project I noticed that it doesn’t work well together with CMake. The problem is that CMake generates files named file.cpp.gcno while gcov searches for file.gcno. Luckily, there is an easy solution.

First things first, in order to use Gcov in CMake you have to pass some flags to g++ so something similar to the following should be in your CMakeLists.txt

set(CMAKE_CXX_FLAGS "-g -O0 -Wall -fprofile-arcs -ftest-coverage")

This would cause the *.cpp.gcno files to be generated next to your object files. Assuming your cpp files were inside a src subdirectory, you will find these files in a folder like build/src/CMakeFiles/project_name.dir.

But we didn’t want this *.cpp.gcno extension, so the solution is to also add the following line in your CMakeLists.txt

set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE 1)

That’s it! By adding that one line your files will just have the *.gcno extension.

Now we can run our tests. After running the tests you can run gcov in the folder where you want to create your *.gcov files. The code below is meant to be executed in a new empty subdirectory inside your build folder and assumes that your source files were in a src directory.

gcov ../../src/*.cpp --object-directory ../src/CMakeFiles/project_name.dir/

Converting string to lowercase at compile time with c++14

Tue, 28 Jul 2015 00:05:00 +0000

The code was completely rewritten and this post was no longer a relevant explanation. The latest code can be found in this Gist with explanations in the comments.

std::bind for unknown variable

Thu, 09 Jul 2015 01:28:00 +0000

I find the std::bind function a very cool thing, it allows storing functions with different parameters in the same list. But you can even do bind calls within bind calls so that at the moment you call the function it will first execute another function and then passing the result as parameter to the function that you call.

But what if you need to bind a parameter to the function but you don’t know yet what variable should be bound? You could use a pointer as parameter and then later set the pointer to the variable of course. But although I will use a pointer I will have it dereference automatically before the function is actually called.

First of all it is important to note that the type of the variable has to be known. I will use void* so that you can reuse the code for any type, but when binding you need to know of which type the variable will be.

Let’s start with defining the function that we will call. This could be any function that uses your chosen type, but I like templates so why not use a templated function that can accept any type? Also let’s make the parameter a reference to point out that we can get even change the variable that the pointer will be pointing to.

template <typename T>
void print(T& obj) {
    std::cout << obj << std::endl;
}

I said I was going to use a pointer, but the function takes the object itself so it has to be dereferenced somewhere along the way. Although the std library provides functions like std::plus for the ‘+’ operator, there is no function for the dereference operator. So we must define our own function. I will again use a template and a void* so that I can reuse this function for any type, but you can make it simpler if it is specifically for one type.

template <typename T>
T& dereference(void* obj) {
    return *static_cast<T*>(obj);
}

We finally arrived at the binding part. I will demonstrate that the same pointer can be used for different types by binding two different print functions. As you can see the code has no idea what variable is going to be passed as parameter of the print function at the moment of binding, the variable hasn’t even been declared yet. Note that you must use std::ref to pass a reference to the pointer, otherwise it gets copied and we can’t make it point to a variable afterwards.

void* ptr = nullptr;
auto func1 = std::bind(print<int>, dereference<int>, std::ref(ptr));
auto func2 = std::bind(print<std::string>, dereference<std::string>, std::ref(ptr));

To finish it off we just have to set our variables and call the function.

int i = 5;
ptr = static_cast<void*>(&i);
func1();

std::string s = "Hello";
ptr = static_cast<void*>(&s);
func2();

That’s it! As you can see, you did not need to have access to the variables at the moment of binding. I hope this ends up being useful to somebody someday.

Final result:

// The function that we are going to call, it just prints out the variable here.
// This function can even receive a reference to the variable and change it!
template <typename T>
void print(T& obj)
{
    std::cout << obj << std::endl;
}

int main()
{
    // We will use a string in this example, but any other type would do (if you give it a valid value below)
    using Type = std::string;

    // The pointer that we are binding contains a nullptr to start with,
    // but it will get a different value after the binding!
    void* ptr = nullptr;

    // The default value is not used, we will change it after the binding is complete.
    // This is done to show that the reference is bound, not the actual value.
    Type obj = "not printed";

    // Now actually bind the parameter to the function.
    // A lambda function is bound here that will dereference the pointer when the function gets called.
    auto func = std::bind(print<Type>,
                          std::bind([](void* obj) -> Type& { return *static_cast<Type*>(obj); },
                                    std::ref(ptr))
                         );

    // Even after binding, we can make the pointer point to a different place!
    ptr = static_cast<void*>(&obj);

    // The value of the variable can be adapted at any time
    obj = "printed";

    // Call the function with the value of the variable that the pointer is currently pointing at
    func();
}

Cross-platform semi-transparent windows

Thu, 25 Jun 2015 01:04:00 +0000

In the previous post I talked about custom shaped windows, in this post I will explain how to create semi-transparent windows in c++ on Windows, Linux and Mac OS X. The full code can be found in the same github repository. Each operating system will again be discussed separately as they require different code.

The alpha variable used below is an unsigned char which means its value is between 0 and 255.

Windows

On windows you just have to make two function calls. The SetWindowLong call makes the window layered, which is needed in order to set the transparency. Then you call the SetLayeredWindowAttributes function to set the alpha value.

To use these functions you just have to include windows.h, you don’t have to link to any libraries like on linux or mac.

SetWindowLong(hWnd, GWL_EXSTYLE, GetWindowLong(hWnd, GWL_EXSTYLE) | WS_EX_LAYERED);
SetLayeredWindowAttributes(hWnd, 0, alpha, LWA_ALPHA);

Linux

On linux the code is a little bit more complicated. We must first get the atom identifier of the opacity property with XInternAtom. Then we set the property with XChangeProperty. Don’t forget to include X11/Xatom.h and add -lX11 to your linker settings in order to use these functions.

There is something strange going on with XChangeProperty at first sight. The 32 looks like the amount of bits, but there is a small catch. Since a long is 64 bit on a 64-bit linux system, it might look like we are passing too many bytes. But if you read the documentation very carefully you find that the data should be a char (8-bit) when passing 8, short (16-bit) when passing 16, but long (32-bit or 64-bit) when passing 32. So the number doesn’t always exactly equal the amount of bits.

Also we can’t just get away with passing 8 and the address of alpha as parameters, since the atom we want to assign to is not a char, hence the conversion to the unsigned long first.

And then we end with calling XFlush to send the request to the X server and XCloseDisplay to free all the memory associated with the display.

Display* display = XOpenDisplay(NULL);
Atom property = XInternAtom(display, "_NET_WM_WINDOW_OPACITY", false);
if (property != None)
{
    unsigned long opacity = (0xffffffff / 0xff) * alpha;
    XChangeProperty(display, wnd, property, XA_CARDINAL, 32, PropModeReplace, (unsigned char*)&opacity, 1);
    XFlush(display);
}
XCloseDisplay(display);

Mac OS X

Mac forces us to use Objective-C or Swift (I used Objective-C here), so we can’t have the implementation in the same .cpp file as the Windows and Linux version. The code below can be placed in a .mm file. Cocoa is needed so you should also add “-framework Cocoa” to the linker flags.

The code is extremely simple though. The alpha value has to be a float between 0 and 1 here so we must first convert our char to the proper format. Then we just set it with calling the setAlphaValue on the window (which has type NSWindow*). The window also has to be told that it is not opaque to make the semi-transparency work, so we pass NO to setOpaque.

CGFloat opacity = alpha / 255.0f;
[window setAlphaValue:opacity];
[window setOpaque:NO];

Cross-platform custom-shaped windows

Sat, 20 Jun 2015 17:45:00 +0000

This post will explain how to create transparent (non-rectangular) windows in c++ on Windows, Linux and Mac OS X. The shape of the window will be determined by an image with a transparent background. If the pixel is transparent then it will not be part of the window. It is assumed that the size of the image and the size of the window are the same.

Each operating system requires different code and will be discussed separately. Below you will find code snippets, but for a full example check this github project which creates a window with a custom shape with SFML.

In the code snippets below get_window, get_pixel_color, image_width and image_height are just placeholders. How you get these properties is up to you. In my example I used SFML, but the code below does not depend on it.

Windows

On Windows we just have to create a region in the wanted shape and use the SetWindowRgn function to set it. To get this region we will combine multiple regions with CombineRgn.

Since we want our region to be based on an image, we must adapt the region pixel by pixel. It might be slightly more performant to detect bigger rectangles in the image so that less regions have to be created, but the effort in doing so is probably larger than the speed gain.

All needed functions come from the Windows API, which means that windows.h has to be included.

Here is the code with explanations in comments:

// Get the window handle from somewhere
HWND hWnd = get_window();

// Create a region that has the size of the entire window
HRGN hRegion = CreateRectRgn(0, 0, image_width, image_height);

// Loop over every pixel in the image
for (unsigned int y = 0; y < image_height; y++)
{
    for (unsigned int x = 0; x < image_width; x++)
    {
        // Check in some way if the pixel is transparent
        if (get_pixel_color(image, x, y).a == 0)
        {
            // Create a 1x1 region that corresponds to the pixel in the image
            HRGN hRegionPixel = CreateRectRgn(x, y, x+1, y+1);

            // Remove the pixel from the region
            CombineRgn(hRegion, hRegion, hRegionPixel, RGN_XOR);

            // Free the memory of the pixel region
            DeleteObject(hRegionPixel);
        }
    }
}

// Set the region of the window (last parameter tells it to redraw the window)
SetWindowRgn(hWnd, hRegion, true);

// Free the memory of the region
DeleteObject(hRegion);

Linux

On linux, non-rectangular windows are not available directly in the X11 library, you will need to use the X Nonrectangular Window Shape Extension Library which is part of the Xext library. On some systems the code will work, while on others it is simply not supported (the availability of the shape extension will be queried at runtime). When linking this code you will have to add “-lX11 -lXext” to the linker flags.

Except for checking the availability, the code is broadly equivalent to the windows version.

// Open a connection to the X server on the default display
Display* display = XOpenDisplay(NULL);

// Check if the shape extension is supported
int event_base;
int error_base;
if (XShapeQueryExtension(display, &event_base, &error_base))
{
    // Get the window handle from somewhere
    Window wnd = get_window();

    // Create a black & white pixmap (depth=1) with the size of the window
    Pixmap pixmap = XCreatePixmap(display, wnd, image_width, image_height, 1);

    // Create a graphics context (without any special values)
    GC gc = XCreateGC(display, pixmap, 0, NULL);

    // Make the entire pixmap white
    XSetForeground(display, gc, 1);
    XFillRectangle(display, pixmap, gc, 0, 0, image_width, image_height);

    // Set the color to black for further draw calls
    XSetForeground(display, gc, 0);

    // Loop over every pixel in the image
    for (unsigned int y = 0; y < image_height; y++)
    {
        for (unsigned int x = 0; x < image_width; x++)
        {
            // Check in some way if the pixel is transparent
            if (get_pixel_color(image, x, y).a == 0)
            {
                // Draw a black 1x1 rectangle on the pixmap at the location of the pixel
                XFillRectangle(display, pixmap, gc, x, y, 1, 1);
            }
        }
    }

    // Set the shape of the window based on the pixmap (window shape = white part of pixmap)
    XShapeCombineMask(display, wnd, ShapeBounding, 0, 0, pixmap, ShapeSet);

    // Free the memory of the graphics context and pixmap
    XFreeGC(display, gc);
    XFreePixmap(display, pixmap);

    // Send the requests to the X server
    XFlush(display);
}

// Free all the memory associated with the display
XCloseDisplay(display);

Mac OS X

Getting custom shapes on Mac is very different from the way we did it on Windows and Linux. You will not have to set any region, you can just tell the window to only be opaque where you draw on it. So by just drawing the image, the window would get the shape of the image. That may sound great, but it introduces a problem when trying to use OpenGL. When drawing with OpenGL you clear the entire screen before drawing, therefore the window would always have a rectangle shape. To work around that you must clear with a transparent color.

Other tutorials show that in order to get a window with a custom shape you have to subclass NSWindow. I will show how to do it without inheriting from it, since you might not have access to the window class directly (e.g. when trying to change the shape of a window created with SFML).

// Get the window handle from somewhere
NSWindow* wnd = get_window();

// Tell the window that some parts have to be transparent
GLint opaque = 0;
[[[wnd contentView] openGLContext] setValues:&opaque forParameter:NSOpenGLCPSurfaceOpacity];
[wnd setBackgroundColor:[NSColor clearColor]];
[wnd setOpaque:NO];

But the above code is not enough if you want to use OpenGL. The NSOpenGLView class overrides the isOpaque function of NSView and makes it return YES while we need it to return NO. In Objective-C we can change the implementation of the function from outside the class. Add the following code somewhere and the NSOpenGLView class and all its subclasses will have this implementation.

@implementation NSOpenGLView (Opaque)
-(BOOL)isOpaque {
    return NO;
}
@end

That’s it. Now just clear the window with a fully transparent color and draw the image on it.