2016-11-28, 12:49
I would like to discuss some architectural fundamentals regading the databases (no matter how they are implemented) and UI interaction, and how we intend to achieve them
@FernetMenta has said “DB operations on the main and renderthread are a major design flaw. OnSomething() methods are not supposed to by hijacked by heavy call like db queries.”
I understand that the general aim is to remove any expensive function calls from both the main and render threads, so that the player and UI can continue smoothly and not be blocked by other activity. But what activities are most expensive and need to be addressed first? And how are we planning to do this?
The comment from Fernet came up in the context of the Song Info dialog, and that a change I had implemented (inline with how other dialogs are done) had somehow missed an opportunity to remove a flaw. But it is not at all clear to me how that could have been achieved (just for that one dialog in time for RC), or even that the music info dialogs do currently present any kind of blocking or heavy processing. It is important to note that the music info dialogs are more than just "popups", they also provide navigation around the music library, and as such I believe it is correct that they fetch the data needed for display as the user navigates through it.
It got me thinking about the UI and db interaction more generally. As I see it there are parts of the UI whose very purpose is to sit on top the db. They display data retrieved from the db, takes input for data to be saved in the db, and provide navigation to other dialogs that display other data retrieved from the db. When using the UI to browse data it is those places that attempt to load all the data from the db into a CFileItem structure that are slow e.g. songs node. The db query is fast, what we then do with the results set is the “heavy processing”. Far better is a design that fetches just the data it needs just in time for display, and keeps movement from results set to some other structures to a minimum.
Some other thread could do the db read/write, but the UI thread would have to wait for it to have something to display I really don’t see the point in that particular separation, what will that gain? Generally db queries are not slow or heavy, it is the crazy way Kodi juggles and manipulates the data it has fetched that needs redesign.
My background is database dependant applications (24/7 mission critical systems), I see things from that view point. There are aspects of Kodi that is just that: it turns a collection of music or video files into an enhanced library that can be explored in a variety of ways and empowers users to browse their collection and select what they want to play. Of course it is much more, and maybe that area needs isolating in some way.
Or maybe I see this all wrong? Either way I would like to discuss how we intend to achieve whatever we want to achieve, so that I and others can collaborate and contribute effectively.
@FernetMenta has said “DB operations on the main and renderthread are a major design flaw. OnSomething() methods are not supposed to by hijacked by heavy call like db queries.”
I understand that the general aim is to remove any expensive function calls from both the main and render threads, so that the player and UI can continue smoothly and not be blocked by other activity. But what activities are most expensive and need to be addressed first? And how are we planning to do this?
The comment from Fernet came up in the context of the Song Info dialog, and that a change I had implemented (inline with how other dialogs are done) had somehow missed an opportunity to remove a flaw. But it is not at all clear to me how that could have been achieved (just for that one dialog in time for RC), or even that the music info dialogs do currently present any kind of blocking or heavy processing. It is important to note that the music info dialogs are more than just "popups", they also provide navigation around the music library, and as such I believe it is correct that they fetch the data needed for display as the user navigates through it.
It got me thinking about the UI and db interaction more generally. As I see it there are parts of the UI whose very purpose is to sit on top the db. They display data retrieved from the db, takes input for data to be saved in the db, and provide navigation to other dialogs that display other data retrieved from the db. When using the UI to browse data it is those places that attempt to load all the data from the db into a CFileItem structure that are slow e.g. songs node. The db query is fast, what we then do with the results set is the “heavy processing”. Far better is a design that fetches just the data it needs just in time for display, and keeps movement from results set to some other structures to a minimum.
Some other thread could do the db read/write, but the UI thread would have to wait for it to have something to display I really don’t see the point in that particular separation, what will that gain? Generally db queries are not slow or heavy, it is the crazy way Kodi juggles and manipulates the data it has fetched that needs redesign.
My background is database dependant applications (24/7 mission critical systems), I see things from that view point. There are aspects of Kodi that is just that: it turns a collection of music or video files into an enhanced library that can be explored in a variety of ways and empowers users to browse their collection and select what they want to play. Of course it is much more, and maybe that area needs isolating in some way.
Or maybe I see this all wrong? Either way I would like to discuss how we intend to achieve whatever we want to achieve, so that I and others can collaborate and contribute effectively.
