[mythtv-theming] Future of UIBlackHoleType in 0.22

George Galt george.galt at gmail.com
Tue Apr 28 16:48:53 UTC 2009


Thanks for the reply:

> To give the best advice it might help if you can give a little more detail on
> what you are trying to achieve. Where is this image coming from for example?

The plugin I'm working on is MythSqueezeBox
(http://sourceforge.net/projects/mythsqueezebox/ -- see the screenshot
for the current display, which will be significantly changed in the
update, but gives an idea of what I'm doing).  The current plugin uses
the UIBlackHoleType to display a bitmap image supplied by the
SqueezeCenter server, which provides streaming music to players able
to connect to is, such as this plugin.  The bitmap image displays
information about the current status of the player -- title, artist,
duration and time remaining of current song, navigation information,
etc.  It is delivered via http at irregular intervals and is rarely
the same.  The images are small (about 4K) but arrive at leas every
second, and because they display both timing and navigation
information, I'd be concerned with any lag induced by writing to, and
then reading from, the disk.  In addition, I also display the current
cover art for the album being played, which is similarly delivered via
http from the server.  In theory, I could write the album art to disk
and then read it from there, but that sounds like a bit of a hack.
However, for the navigation information from the server changes so
often it would result in a lot of disk activity.

> Anything in libmyth/* relating to the UI is deprecated and is being replaced
> with libmythui. You mention UIImageType, which is the old widget but I suspect
> you meant MythUIImage. UIBlackHoleType was not only deprecated in the old UI,
> but it does not exist at all in the new library.

Oops, I meant MythUIImage.  Sorry.

> MythUIImage::SetImage(MythImage) is deprecated because it bypasses the image
> cache and for that reason it was scheduled for removal. It's since been
> pointed out that there are limited circumstances where bypassing the image
> cache is a good thing. MythZoneMinder for example needs to display ever
> changing and unique images, the same image will never be shown twice so the
> image cache provides no benefits. The deprecated attribute was left in place
> for now to discourage it's use and to help highlight remaining code which
> still used it.

I've got a similar need with the navigation information, and with
displaying cover art.  Because I can't count on the SqueezeCenter
server being on the same computer as the frontend (or even the
backend), and because the SqueezeCenter server delivers the images via
an http connection, the image cache does little for me as well.  I
tried looking at the code for the preview window in the "watch
recordings" screen, but it seems to use images read from the disk,
rather than displaying the images from the video file dynamically
(which is what I assumed happened).

> It is possible to use MythUIImage this way, but as explained it has downsides
> and it might not be the best way to achieve what you want which is why I asked
> for more information. UIBlackHoleType will probably never return, for video
> there will be a dedicated video widget and the mythmusic visualiser is
> currently undecided.
> --

If I haven't given enough info, let me know and I'll try to provide more.



More information about the mythtv-theming mailing list