Kivy image manipulations with Mesh and Textures

If you want to give a little life to interactive (or not) elements, it’s always nice to have more tricks to manipulate images for nifty effects.

One of such ways is mapping a Texture on a special canvas instruction, that will distort your texture based on the position of its points.

[kivy.graphics.Mesh](http://kivy.org/docs/api-kivy.graphics.html#kivy.graphics.Mesh) is such an instruction, and it has a simple interface, if not 100% straightforward, you basically call it this way.

Mesh:
vertices: (x1, y1, s1, v1, x2, y2, s2, v2, x3, y3, s3, v3...)
indices: (1, 2, 3...)
texture: some_texture
mode: some_mode

where all: x mean the horizontal coordinate of a point y mean the vertical coordinate of a point s mean the horizontal position of the texture attached to this point (between 0 and 1) v mean the vertical position of the texture attached to this point (between 0 and 1)

indices is useful if, for some (very good) reason, you don’t want to give the points in the order you’ll use them, or if you want to refer to a point multiple time (this won’t be demonstrated in this blog post, but try to think about a grid mapping, for example), now we will use it in the most simple way, just give the range of your number of points.

the texture needs to be a texture object, you can get such an object by getting the texture property of a [CoreImage](http://kivy.org/docs/api-kivy.core.image.html#kivy.core.image.Image) or an Image (or even a Label, if you want to).

Let’s say we have an image, for example, kivy logo.

from kivy.core.image import Image as CoreImage

texture = CoreImage('data/logo/kivy-icon-512.png').texture

(this will work wherever you are, because kivy look at his images anyway :))

This image is a circle, lets use that to cut it into a virtual pie and assign a part of the texture to each part, we’ll be using the triangle_fan mode of Mesh, that is a perfect fit for such an operation.

# the central point
points = [Window.width / 2, Window.height / 2, .5, .5]

# now go around
    i = 0
    while i < 2 * pi:
        i += 0.01 * pi
        points.extend([
    Window.width / 2 + cos(i) * 100,
    Window.height / 2 + sin(i) * 100,
    .5 + sin(i),
    .5 + cos(i)])

put that in a more complete program, and you get this:

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
Widget:
    canvas:
        Color:
            rgba: 1, 1, 1, 1
        Mesh:
            vertices: app.mesh_points
            indices: range(len(app.mesh_points) / 4)
            texture: app.mesh_texture
            mode: 'triangle_fan'
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * 100,
                Window.height / 2 + sin(i) * 100,
                .5 + cos(i),
                .5 + sin(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

Now, this is not very impressive, we just have an image, there were much simpler ways to do that!

But now, we can tweek the rendering a lot, lets add some offseting of the texture, some radius change, and some wobbling, with sliders to control all this.

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty, NumericProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
BoxLayout:
    Widget:
        canvas:
            Color:
                rgba: 1, 1, 1, 1
            Mesh:
                vertices: app.mesh_points
                indices: range(len(app.mesh_points) / 4)
                texture: app.mesh_texture
                mode: 'triangle_fan'
    BoxLayout:
        orientation: 'vertical'
        size_hint_x: None
        width: 100
        Slider:
            value: app.offset_x
            on_value: app.offset_x = args[1]
            min: -1
            max: 1
        Slider:
            value: app.offset_y
            on_value: app.offset_y = args[1]
            min: -1
            max: 1
        Slider:
            value: app.radius
            on_value: app.radius = args[1]
            min: 10
            max: 1000
        Slider:
            value: app.sin_wobble
            on_value: app.sin_wobble = args[1]
            min: -50
            max: 50
        Slider:
            value: app.sin_wobble_speed
            on_value: app.sin_wobble_speed = args[1]
            min: 0
            max: 50
            step: 1
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)
    radius = NumericProperty(500)
    offset_x = NumericProperty(.5)
    offset_y = NumericProperty(.5)
    sin_wobble = NumericProperty(0)
    sin_wobble_speed = NumericProperty(0)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                Window.height / 2 + sin(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                self.offset_x + sin(i),
                self.offset_y + cos(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

which gives us:

Kivy image manipulations with Mesh and Text

Now we are talking!

Kivy image manipulations with Mesh and Textures

If you want to give a little life to interactive (or not) elements, it’s always nice to have more tricks to manipulate images for nifty effects.

One of such ways is mapping a Texture on a special canvas instruction, that will distort your texture based on the position of its points.

[kivy.graphics.Mesh](http://kivy.org/docs/api-kivy.graphics.html#kivy.graphics.Mesh) is such an instruction, and it has a simple interface, if not 100% straightforward, you basically call it this way.

Mesh:
vertices: (x1, y1, s1, v1, x2, y2, s2, v2, x3, y3, s3, v3...)
indices: (1, 2, 3...)
texture: some_texture
mode: some_mode

where all: x mean the horizontal coordinate of a point y mean the vertical coordinate of a point s mean the horizontal position of the texture attached to this point (between 0 and 1) v mean the vertical position of the texture attached to this point (between 0 and 1)

indices is useful if, for some (very good) reason, you don’t want to give the points in the order you’ll use them, or if you want to refer to a point multiple time (this won’t be demonstrated in this blog post, but try to think about a grid mapping, for example), now we will use it in the most simple way, just give the range of your number of points.

the texture needs to be a texture object, you can get such an object by getting the texture property of a [CoreImage](http://kivy.org/docs/api-kivy.core.image.html#kivy.core.image.Image) or an Image (or even a Label, if you want to).

Let’s say we have an image, for example, kivy logo.

from kivy.core.image import Image as CoreImage

texture = CoreImage('data/logo/kivy-icon-512.png').texture

(this will work wherever you are, because kivy look at his images anyway :))

This image is a circle, lets use that to cut it into a virtual pie and assign a part of the texture to each part, we’ll be using the triangle_fan mode of Mesh, that is a perfect fit for such an operation.

# the central point
points = [Window.width / 2, Window.height / 2, .5, .5]

# now go around
    i = 0
    while i < 2 * pi:
        i += 0.01 * pi
        points.extend([
    Window.width / 2 + cos(i) * 100,
    Window.height / 2 + sin(i) * 100,
    .5 + sin(i),
    .5 + cos(i)])

put that in a more complete program, and you get this:

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
Widget:
    canvas:
        Color:
            rgba: 1, 1, 1, 1
        Mesh:
            vertices: app.mesh_points
            indices: range(len(app.mesh_points) / 4)
            texture: app.mesh_texture
            mode: 'triangle_fan'
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * 100,
                Window.height / 2 + sin(i) * 100,
                .5 + cos(i),
                .5 + sin(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

Now, this is not very impressive, we just have an image, there were much simpler ways to do that!

But now, we can tweek the rendering a lot, lets add some offseting of the texture, some radius change, and some wobbling, with sliders to control all this.

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty, NumericProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
BoxLayout:
    Widget:
        canvas:
            Color:
                rgba: 1, 1, 1, 1
            Mesh:
                vertices: app.mesh_points
                indices: range(len(app.mesh_points) / 4)
                texture: app.mesh_texture
                mode: 'triangle_fan'
    BoxLayout:
        orientation: 'vertical'
        size_hint_x: None
        width: 100
        Slider:
            value: app.offset_x
            on_value: app.offset_x = args[1]
            min: -1
            max: 1
        Slider:
            value: app.offset_y
            on_value: app.offset_y = args[1]
            min: -1
            max: 1
        Slider:
            value: app.radius
            on_value: app.radius = args[1]
            min: 10
            max: 1000
        Slider:
            value: app.sin_wobble
            on_value: app.sin_wobble = args[1]
            min: -50
            max: 50
        Slider:
            value: app.sin_wobble_speed
            on_value: app.sin_wobble_speed = args[1]
            min: 0
            max: 50
            step: 1
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)
    radius = NumericProperty(500)
    offset_x = NumericProperty(.5)
    offset_y = NumericProperty(.5)
    sin_wobble = NumericProperty(0)
    sin_wobble_speed = NumericProperty(0)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                Window.height / 2 + sin(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                self.offset_x + sin(i),
                self.offset_y + cos(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

which gives us:

Kivy image manipulations with Mesh and Text

Now we are talking!

Creating a Kivy layout: the SparseGridLayout

I thought for a change I’d try for a shorter post on a single quick subject, so I’m going to quickly explain a simple Kivy layout I created, the SparseGridLayout. The post is standalone, but would go well with ideas from my Kivy Crash Course, especially the recent videos trying to draw ideas together to make widgets or specifically focusing on layouts.

The point here is that Kivy has a built in GridLayout, but it doesn’t cover all use cases for widgets in a grid, which is sometimes confusing to users who’ve seen grid widgets in other places and expected a slightly different behaviour. The problem is that the GridLayout fills widgets in from the top. That means for instance if there are 3 columns, you can’t place a widget in the third row without first adding 6 widgets to fill the first two rows. That’s just inefficient and wasteful if all you wanted was a small number of widgets in a grid.

So, my SparseGridLayout is a very simple layout that has a number of rows or columns, and checks its children for a row and column property. It then resizes them automatically to be placed in the right grid cell. That means we don’t need any extra widgets, which is much more efficient if we want a grid with not many entries, hence sparse grid layout.

We can start with a FloatLayout base, then all we need to do is set our grid children’s size_hint and pos_hint properties appropriately for the grid and call the FloatLayout‘s normal layout method to actually place them in the grid positions/shapes for us.

We can start by making our layout class:

from kivy.uix.floatlayout import FloatLayout
from kivy.properties import NumericProperty, ReferenceListProperty

class SparseGridLayout(FloatLayout):
    rows = NumericProperty(1)
    columns = NumericProperty(1)
    shape = ReferenceListProperty(rows, columns)

That creates a basic class that doesn’t have any more actual behavior than the FloatLayout alone, but has a few new properties. It’ll hopefully all make sense if you’ve used Kivy a little or followed my crash course, though the ReferenceListProperty may be new - this takes multiple other properties and lets us access them as a list, so for instance referencing or setting shape[0] really updates the rows property, including calling all its associated events etc.. At the same time, the shape is also a real property, with its own events. Do experiment with this if the explanation is not clear.

Now, to make our layout actually rearrange its children to the grid, we need to override its do_layout method, which is what’s called whenever it or its children are updated.

def do_layout(self, *args):
    shape_hint = (1. / self.columns, 1. / self.rows)
    for child in self.children:
        child.size_hint = shape_hint
        if not hasattr(child, 'row'):
            child.row = 0
        if not hasattr(child, 'column'):
            child.column = 0

        child.pos_hint = {'x': shape_hint[0] * child.row,
                          'y': shape_hint[1] * child.column}
    super(SparseGridLayout, self).do_layout(*args)

This iterates over all the SparseGridLayout‘s children, setting their size_hint so that they’ll fit exactly in a grid cell (as per the rows and columns properties we set above). It then checks if they have a row or column property, setting it to 0 if not - I’ve chosen that my rows and columns should be zero-indexed, you could modify that if you like. After that, it sets their pos_hint such that they’re placed in the right place. I’ve deliberately let this work with floats, so for instance they could be in column 2.5 to be halfway between the integer columns, so the layout is extra flexible.

The final step is calling the original do_layout method of the FloatLayout. The magic is that all we did is set the child widgets size_hint and pos_hint so that the widgets align to a grid - the FloatLayout itself already knows how to actually set their positions and sizes based on this information. By making use of Kivy’s existing layout abilities, we’ve saved ourself a lot of work.

Finally, I also added a class to represent entries in the grid:

class GridEntry(EventDispatcher):
    row = NumericProperty(0)
    column = NumericProperty(0)

This is very simple, but it means you can do for example:

class GridLabel(Label, GridEntry):
    pass

The GridLabel is thereby a Label that already has row and column properties, so it will behave properly in our SparseGridLayout. We don’t strictly need to do this, we could add the row and column any other way, but this is neat and makes it totally clear what we’re using our widgets for.

That’s everything! With just a few simple modifications we’ve made a whole new Layout widget that can place its children in rows and columns of a grid. Maybe you’ll find that useful, but more generally I hope this demonstrates the general principles of thinking about Layouts and using Kivy’s existing mechanisms to do most of the work.

You can find all this code at my sparsegridlayout github repository, which also includes a simple demonstration App so you can test the new layout if you like.

Creating a Kivy layout: the SparseGridLayout

I thought for a change I’d try for a shorter post on a single quick subject, so I’m going to quickly explain a simple Kivy layout I created, the SparseGridLayout. The post is standalone, but would go well with ideas from my Kivy Crash Course, especially the recent videos trying to draw ideas together to make widgets or specifically focusing on layouts.

The point here is that Kivy has a built in GridLayout, but it doesn’t cover all use cases for widgets in a grid, which is sometimes confusing to users who’ve seen grid widgets in other places and expected a slightly different behaviour. The problem is that the GridLayout fills widgets in from the top. That means for instance if there are 3 columns, you can’t place a widget in the third row without first adding 6 widgets to fill the first two rows. That’s just inefficient and wasteful if all you wanted was a small number of widgets in a grid.

So, my SparseGridLayout is a very simple layout that has a number of rows or columns, and checks its children for a row and column property. It then resizes them automatically to be placed in the right grid cell. That means we don’t need any extra widgets, which is much more efficient if we want a grid with not many entries, hence sparse grid layout.

We can start with a FloatLayout base, then all we need to do is set our grid children’s size_hint and pos_hint properties appropriately for the grid and call the FloatLayout‘s normal layout method to actually place them in the grid positions/shapes for us.

We can start by making our layout class:

from kivy.uix.floatlayout import FloatLayout
from kivy.properties import NumericProperty, ReferenceListProperty

class SparseGridLayout(FloatLayout):
    rows = NumericProperty(1)
    columns = NumericProperty(1)
    shape = ReferenceListProperty(rows, columns)

That creates a basic class that doesn’t have any more actual behavior than the FloatLayout alone, but has a few new properties. It’ll hopefully all make sense if you’ve used Kivy a little or followed my crash course, though the ReferenceListProperty may be new - this takes multiple other properties and lets us access them as a list, so for instance referencing or setting shape[0] really updates the rows property, including calling all its associated events etc.. At the same time, the shape is also a real property, with its own events. Do experiment with this if the explanation is not clear.

Now, to make our layout actually rearrange its children to the grid, we need to override its do_layout method, which is what’s called whenever it or its children are updated.

def do_layout(self, *args):
    shape_hint = (1. / self.columns, 1. / self.rows)
    for child in self.children:
        child.size_hint = shape_hint
        if not hasattr(child, 'row'):
            child.row = 0
        if not hasattr(child, 'column'):
            child.column = 0

        child.pos_hint = {'x': shape_hint[0] * child.row,
                          'y': shape_hint[1] * child.column}
    super(SparseGridLayout, self).do_layout(*args)

This iterates over all the SparseGridLayout‘s children, setting their size_hint so that they’ll fit exactly in a grid cell (as per the rows and columns properties we set above). It then checks if they have a row or column property, setting it to 0 if not - I’ve chosen that my rows and columns should be zero-indexed, you could modify that if you like. After that, it sets their pos_hint such that they’re placed in the right place. I’ve deliberately let this work with floats, so for instance they could be in column 2.5 to be halfway between the integer columns, so the layout is extra flexible.

The final step is calling the original do_layout method of the FloatLayout. The magic is that all we did is set the child widgets size_hint and pos_hint so that the widgets align to a grid - the FloatLayout itself already knows how to actually set their positions and sizes based on this information. By making use of Kivy’s existing layout abilities, we’ve saved ourself a lot of work.

Finally, I also added a class to represent entries in the grid:

class GridEntry(EventDispatcher):
    row = NumericProperty(0)
    column = NumericProperty(0)

This is very simple, but it means you can do for example:

class GridLabel(Label, GridEntry):
    pass

The GridLabel is thereby a Label that already has row and column properties, so it will behave properly in our SparseGridLayout. We don’t strictly need to do this, we could add the row and column any other way, but this is neat and makes it totally clear what we’re using our widgets for.

That’s everything! With just a few simple modifications we’ve made a whole new Layout widget that can place its children in rows and columns of a grid. Maybe you’ll find that useful, but more generally I hope this demonstrates the general principles of thinking about Layouts and using Kivy’s existing mechanisms to do most of the work.

You can find all this code at my sparsegridlayout github repository, which also includes a simple demonstration App so you can test the new layout if you like.

Kivy – Mouse cursor on Rapsberry Pi

It’s no news that kivy have been ported to Rapsberry Pi, it happened nearly a year ago, and works quite well, especially if you start the app without an X server, since kivy draw directly to EGL (don’t ask me :)), it doesn’t need it.

However, there is a little issue about it if you don’t have a touch screen, you can use your mouse, but you don’t see any cursor, whever you are in X or not, because in X, kivy display is actually on top of the X cursor, and without X, nothing even try to draw a mouse cursor.

A few months ago, i wrote a quick hack, adding a few graphic instructions to the egl window provider, and made the probsys driver used on rpi directly update the position of this instruction. It worked, but it wasn’t really a general solution.

So after procrastinating a proper solution for a long time, i finally got my act together and added the cursor display as an option to the touchring module of kivy, along with options of what image to use, offsets and so on, and added the code that made the mouse driver dispatch pos to window’s mouse_pos property.

So here it is, you can find it here until the PR is merged.

Kivy – Mouse cursor on Rapsberry Pi

It’s no news that kivy have been ported to Rapsberry Pi, it happened nearly a year ago, and works quite well, especially if you start the app without an X server, since kivy draw directly to EGL (don’t ask me :)), it doesn’t need it.

However, there is a little issue about it if you don’t have a touch screen, you can use your mouse, but you don’t see any cursor, whever you are in X or not, because in X, kivy display is actually on top of the X cursor, and without X, nothing even try to draw a mouse cursor.

A few months ago, i wrote a quick hack, adding a few graphic instructions to the egl window provider, and made the probsys driver used on rpi directly update the position of this instruction. It worked, but it wasn’t really a general solution.

So after procrastinating a proper solution for a long time, i finally got my act together and added the cursor display as an option to the touchring module of kivy, along with options of what image to use, offsets and so on, and added the code that made the mouse driver dispatch pos to window’s mouse_pos property.

So here it is, you can find it here until the PR is merged.

Stress-testing kivy with the recorder module.

In a framework like kivy, or any app using it it can happen that there is a bug that precise interaction is needed to reproduce, and it can be frustrating to manually test every time, sometime a complex or repetitive manipulation.

Kivy has a not-so-well known module, called recorder that allows to record and replay user inputs, both touch and keyboard events.

python main.py -m recorder

f8 to record, f7 to replay, ‘simple as that!

It’s helpful, but in some cases, something is missing, for example, an user reported a memory leak in 1.7.2, apparently windows specific, that happened to crash the app (the touchracer demo) after a lot of touches, over a very long time (hours) of usage. You don’t want to record hours of touches just to replay them, at least, i didn’t want to.

So i did a little update to this module, to add the feature of playing the same replay times and time over, i recorded a sample of one touch (the touch duration didn’t matter), as i wasn’t very fast (i’m only human), this recording lasted nearly a second (starting to record, touch down, touch up, stoping record), so i fired my editor of choice, and edited the recorder.kvi to:

#RECORDER1.0
(.0118309783935547, 'begin', 1, {'is_touch': True, 'profile': ['pos'], 'sy': 0.9688715953307393, 'sx': 0.08692628650904033})
(.0642069625854492, 'end', 1, {'is_touch': True, 'profile': ['pos'], 'sy': 0.9688715953307393, 'sx': 0.08692628650904033})

Note that the times are now quite low, so this recording will be played dozens of time a second, and i removed over events, such as the keyboard ones.

With this, it was a lot easier to observe the leak on 1.7.2, memory was raising fast enough to observe.

Now, i knew we had a few memory leak fixes in master, so to check we had gotten ride of this one, i just had to replay this very same test on the last version.
And if needed, git-bisect will tell me which one did fix it, without too much effort on my side.

And it was indeed fixed!

Stress-testing kivy with the recorder module.

In a framework like kivy, or any app using it it can happen that there is a bug that precise interaction is needed to reproduce, and it can be frustrating to manually test every time, sometime a complex or repetitive manipulation.

Kivy has a not-so-well known module, called recorder that allows to record and replay user inputs, both touch and keyboard events.

python main.py -m recorder

f8 to record, f7 to replay, ‘simple as that!

It’s helpful, but in some cases, something is missing, for example, an user reported a memory leak in 1.7.2, apparently windows specific, that happened to crash the app (the touchracer demo) after a lot of touches, over a very long time (hours) of usage. You don’t want to record hours of touches just to replay them, at least, i didn’t want to.

So i did a little update to this module, to add the feature of playing the same replay times and time over, i recorded a sample of one touch (the touch duration didn’t matter), as i wasn’t very fast (i’m only human), this recording lasted nearly a second (starting to record, touch down, touch up, stoping record), so i fired my editor of choice, and edited the recorder.kvi to:

#RECORDER1.0
(.0118309783935547, 'begin', 1, {'is_touch': True, 'profile': ['pos'], 'sy': 0.9688715953307393, 'sx': 0.08692628650904033})
(.0642069625854492, 'end', 1, {'is_touch': True, 'profile': ['pos'], 'sy': 0.9688715953307393, 'sx': 0.08692628650904033})

Note that the times are now quite low, so this recording will be played dozens of time a second, and i removed over events, such as the keyboard ones.

With this, it was a lot easier to observe the leak on 1.7.2, memory was raising fast enough to observe.

Now, i knew we had a few memory leak fixes in master, so to check we had gotten ride of this one, i just had to replay this very same test on the last version.
And if needed, git-bisect will tell me which one did fix it, without too much effort on my side.

And it was indeed fixed!