[mwkurt]

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

[amet]

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

[mwkurt]

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

As I said, I am not a coder, so I can't give you the snippet of code or anything to help. I am not sure it is a bug rather than a change in the way XBMC works. All I know is that between Dharma and Eden, the XBMC code itself changed, and not for the better. PseudoTV was not the only plugin affected by this change as can be seen in this thread: http://forum.xbmc.org/showthread.php?tid=108580, unfortunately, no developers took notice of the thread or didn't bother to respond. Perhaps you could maybe talk to the plugin writers to find out what or why things changed between versions. I appreciate your taking the time to look at this amet. I hope that someone can look into it because I always thought that an upgrade to a program was supposed to make things better, not worse for the enduser.
With that out of the way, before I get slammed, I love XBMC and appreciate all of the work that goes into it. Thank you very much.
Mark

[Memphiz]

You really think we are introducing regressions by intention? Impressive. Beside that you are already talking to an addon author with amet...

[amet]

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

[Jason102]

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.

[amet]

one thing I know would help with speeding things up is instead of doing self.addControl() for each individual button, if you did that for all the items at once.

Code:

addControls(...)
  addControls(self, List) -- Add a list of Controls to this window.

[jmarshall]

The same is available for removeControls as well. Both were added specifically for your use case.

[Jason102]

Ah, fantastic, thanks guys. As far as I can tell, those functions do result in just the speed boost that I needed.

[spoyser]

Have the addControls and removeControls been broken in a recent nightly.

As one of the developers of the TVCatchup EPG plugin we recently noticed a large number of errors from RaspBMC RC5 users.

It turns out that this is because the RaspBMC code is based on a nightly in which the addControls and removeControls (which we rely massively on, since we often draw 50+ controls at once) no longer appear to give the speed increase that they used to.

The functions are available still they just don't seem to work efficiently anymore.

Any comments would be most appreciated.

Edit
answered http://trac.xbmc.org/ticket/13538

[jfcarroll]

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).