Mailing List Archive

Future of UIBlackHoleType in 0.22
All:

I originally posted to the dev list, but it was suggested that this
question might be better answered here.

Having looked through the plugins and libmythui files in 0.22 so that
I can start on porting a plugin, I've noticed an issue I'd like a
little guidance on. I need to draw an animated image onto a specified
area of the screen. Looking at UIImageType, it seems that using
SetImage( QImage * ) is being deprecated (I'm not exactly sure why,
but that's beside the point). This leaves me with using
UIBlackHoleType, which appears to only be used by Mythmusic to draw
the visualization -- it even states in the libmythui files that this
is the only reason it is being preserved.

My question is twofold. First, is there a way to draw a QPixmap or
QImage directly to a UIImageType without first writing to a local
file, and, second, if not, what is the future of UIBlackHoleType?
Alternatively, if someone has another suggestion for drawing an image
directly to a section of a theme, I'd appreciate it.

George
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming
Re: Future of UIBlackHoleType in 0.22 [ In reply to ]
On Tuesday 28 April 2009 16:06:17 George Galt wrote:
> Having looked through the plugins and libmythui files in 0.22 so that
> I can start on porting a plugin, I've noticed an issue I'd like a
> little guidance on. I need to draw an animated image onto a specified
> area of the screen. Looking at UIImageType, it seems that using
> SetImage( QImage * ) is being deprecated (I'm not exactly sure why,
> but that's beside the point). This leaves me with using
> UIBlackHoleType, which appears to only be used by Mythmusic to draw
> the visualization -- it even states in the libmythui files that this
> is the only reason it is being preserved.

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?

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.

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.

> My question is twofold. First, is there a way to draw a QPixmap or
> QImage directly to a UIImageType without first writing to a local
> file, and, second, if not, what is the future of UIBlackHoleType?
> Alternatively, if someone has another suggestion for drawing an image
> directly to a section of a theme, I'd appreciate it.

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.
--
Stuart Morgan
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming
Re: Future of UIBlackHoleType in 0.22 [ In reply to ]
Stuart:

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.

Thanks,

George
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming
Re: Future of UIBlackHoleType in 0.22 [ In reply to ]
Stuart:

I am hoping you can give me some guidance on how to best approach
solving this issue. I may have overloaded you on information last
time around.

On Tue, Apr 28, 2009 at 12:48 PM, George Galt <george.galt@gmail.com> wrote:
> Stuart:
>
> 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?
>>
>

I've attached an image that shows three examples of the image I need
to display. As you can see, the image arrives at least once each
second from the server as a bitmap and it's contents are dictated by
the status of the player and the song playing -- effectively the image
is never the same. Since the information is time-critical, especially
when the display is showing menu information rather than song
information, I am concerned about latency issues with writing the
image first to disk. I also wanted to add a equalizer display, which
would require direct writes to the screen both because of latency
issues and because the image would be generated on the fly.

Short of using the deprecated MythUIImage.SetImage( QPixmap ) method,
is there any other way to write directly to a widget?

George
Re: Future of UIBlackHoleType in 0.22 [ In reply to ]
On Tuesday 05 May 2009 19:31:37 George Galt wrote:
> Short of using the deprecated MythUIImage.SetImage( QPixmap ) method,
> is there any other way to write directly to a widget?

No and using SetImage() would be correct for what you are attempting to
achieve.

--
Stuart Morgan
_______________________________________________
mythtv-theming mailing list
mythtv-theming@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-theming