Posts: 1,328
Joined: Mar 2010
Reputation:
19
mwkurt
Posting Freak
Posts: 1,328
Hello,
This question is for the developers and code writers, of which I am not.
Between Dharma and Eden there was some kind of a change that affected in a negative way, one of the most popular Plugins for XBMC, PseudoTV. The change affects the EPG scrolling speed when it is called up and slows down the experience very much. This was the explanation given by Jason, who wrote PTV:
There was the ability to call xbmcgui.lock and unlock. These locked the drawing in XBMC until unlock was called so that you didn't have to deal with processing each GUI item as they were created or modified, it could just deal with them all at once. This is now deprecated, although in reality it's now just a stub. I'm guessing that there were conflicts with the dirty region feature. The farthest I ever got with the discussion was this. I've actually been messing a bit with it today in the hopes of coming up with some magical method for making this better...no luck so far.
So my question is, is there any plans on fixing this by team XBMC in a future version (i.e Frodo)? I would like to be able to move forward from Dharma, but seeing as I use PTV almost exclusively now with XBMC, I won't because of this problem.
Thanks,
Mark
Posts: 4,137
Joined: Jul 2009
Reputation:
48
amet
Retired Team-Kodi Member
Posts: 4,137
I fail to see what the issue is, if xbmcgui.lock/unlock is not needed then author should just remove it.
how does it impact the addon? atv1(very slow CPU) would have issues with drawing thousands of GUI elements but on any average configuration that would not be a problem.
any chance you have a code that shows this "error" so that we could try to trace it? also, if this is a bug, it should go on trac rather than here....
cheers,
amet
Posts: 16,946
Joined: Feb 2011
Reputation:
256
You really think we are introducing regressions by intention? Impressive. Beside that you are already talking to an addon author with amet...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much:
click here
HowTo setup NFS for Kodi:
NFS (wiki)
HowTo configure avahi (zeroconf):
Avahi_Zeroconf (wiki)
READ THE IOS FAQ!:
iOS FAQ (wiki)
Posts: 4,137
Joined: Jul 2009
Reputation:
48
amet
Retired Team-Kodi Member
Posts: 4,137
some of my addons used the xbmcgui.lock/unlock but I removed it about a year ago and never had an issue. if there is an issue with Pseudo i would love to hear from the author. 4 complaints on the other thread and you on here and no one has given an example of the code that slows things down.
cheers,
amet
Posts: 566
Joined: Nov 2010
Reputation:
30
Just noticed this thread, so I might as well chime in (oddly enough, I noticed the thread because I was again looking for a solution to this). So here is what's going on. As you may or may not know, PseudoTV emulates real TV with your own video library. This includes the creation of an EPG where the user can view and select the available shows.
The EPG is composed primarily of a few dozen buttons (3 - 5 on average per row, 5 rows). The user is allowed to move through the visible buttons. The problem comes when scrolling beyond the edge of the visible buttons...ie. going too far down, too far up, to the left, or to the right. This requires the removal and redrawing of all buttons. Going up or down have been optimized a bit...the single row that is disappearing is removed, most buttons are just moved up one row, and a new row is drawn.
When going left or right, though, every row really needs to be redrawn. When I previously used lock / unlock with Dharma, this was done very quickly. Since the removal of those functions, I believe what is happening is that XBMC is actually redrawing each control immediately (possibly waiting for vsync?) and so redrawing is very slow...up to 2 or 3 seconds to do all of the buttons. Additionally, you can actually see the redraw happening, which is a bit unsightly.
Again, I've tried to optimize this by not removing buttons but moving them offscreen and then moving and resizing them to fill new roles. This has helped as it removes the delay for creation, but even changing position is slower than I'd like.
As the documentation stated, the lock / unlock was put into place to speed up lots of graphical manipulation. I imagine most plugins do not do a significant amount of graphics at once (especially while video is playing) which is why the loss of lock / unlock wasn't really noticed. It has affected my plugin, though. If they were removed for the good of the project as a whole, that is completely understandable. More than anything, I hope to find some alternative clever thing that I can do in order to return drawing to the speed it was in Dharma.
Posts: 26,215
Joined: Oct 2003
Reputation:
187
The same is available for removeControls as well. Both were added specifically for your use case.
Posts: 566
Joined: Nov 2010
Reputation:
30
Ah, fantastic, thanks guys. As far as I can tell, those functions do result in just the speed boost that I needed.
Posts: 492
Joined: Dec 2006
Reputation:
5
This was fixed yesterday. addControls and removeControls were added to address exactly what you're talking about here.
I understand the use of the guilock but ideally it shouldn't exist at all, let alone the ability to manipulate it from Python. The single biggest source of deadlocks in the codebase has been contention between the python GIL and the graphics lock (which is one of the reasons we moved to the new codegenerated engine - it completely isolates the python and C-locking sides so that they don't overlap at all).
The stubs are still there so scripts that used it wouldn't break with a compilation/runtime failure. That's not to say they will work exactly the same way between Dharma and Eden.
I'm not sure who wrote the PseudoTV script but personally it's one of my favorites also. It's also a great debug tool because it's so brittle (it actually has callback order dependencies, which are not guaranteed, that the author probably doesn't even know about - so if PseudoTV still works after a major overhaul, the python API is probably still backward compatible).