Hyperion Entertainment Message Boards

Hi

I think I found out about 3 bugs in MultiView, 1 minor (false rendering) and 2 grave (freezes up the whole system). It would be interesting to see, if others can reproduce this as well. My config is:
OS 4.1 Update 2 on Sam440Flex 800 Mhz, 1 GB Ram, Radeon 9250 128 MB

The following versions of components involved are present of my system:
MultiView: 53.2 (20.09.2009)
amigaguide.library 53.2 (20.09.2009)
AmigaGuide datatype: 53.2 (20.09.2009)
datatype.library: 53.4 (04.11.2009)

Here's a little test suite to try it out:
http://home.datacomm.ch/mrupp/Test/Test.lha

1. Grave, the 1st:
When MultiView is showing an image, that has been called by an AmigaGuide document (means: not directly opened in MultiView but having opened an AmigaGuide document that has a link which referes to an image file, see "Link to 'Image.jpg'" in my Test.guide), now resizing the MultiView window totally freezes my system, especially (but not only) when making the window smaller.
This only happens when having "Resize window with contents" in GUI prefs is activated (as it is as default).

2. Grave, the 2nd:
Having an (old) AmigaGuide document that still would use the (deprecated) tag 'close' or 'quit' (which are still rendered as buttons by MultiView), clicking one of these buttons and then clicking on another link (a few times) also freezes my system). Try it out with my Test.guide.

3. Minor:
Now, to try this out, I would recommend to deactive "Resize window with contents" in GUI prefs first, to avoid your system being frozen. To reproduce, do the following:
- Open my Test.guide
- Click "Link to 'Image.jpg'"
- Resize the MultiView window to minimal height and a width, that will break to top line of buttons to a 2nd line of buttons.
--> Result: part of the image is drawn over the bottom border of the window.

Btw.: this last bug can also be reprocued on OS3.9 (and probably lower), so it might be an ancient one.

It would be great to see a fix for this in the upcoming update 3...

Hello,

And Multiview don't play Gif anim pictures.

Mrodfr wrote:Hello,

And Multiview don't play Gif anim pictures.

That's not a bug of Multiview. It is because the OS-included gif datatype is implemented as a subclass of picture.datatype instead of animation.datatype. The OS-included gif datatype misuses a feature of newer picture.datatype versions that's meant to allow to support formats containing several versions of the same image in different sizes and colour formats like f.e. .ico and .icns formats and definitely not meant to be used for animation frames.

To be honest there is really no good way of supporting formats like gif which can be used for both still pictures as well as animations in the current datatypes system.

For a gif datatype that is implemented as a proper animation.datatype subclass you can check out this link:
http://os4depot.net/index.php?function= ... nim_dt.lha

Hello,

I have tested the gifanim datatype provided on the link with multiview.

First sample, a verry small gifanim play well but some frame have background colors inverted.

Second sample work fine (a much bigger gifanim).

The common problem is even with the small gif anim, the CPU usage on my SAM440ep is 100% :-\

BTW, this is great that something exist and must be added on the OS direclty. Thanks for the advice

Mrodfr wrote:The common problem is even with the small gif anim, the CPU usage on my SAM440ep is 100% :-\

The problem is the animation.datatype superclass is rather outdated and not terribly efficient.

It needs updating to support truecolour formats, which should improve the efficiency of the entire thing straight off, although I'm sure there are lots of other optimisations possible (writing animation.datatype subclasses is a PITA, mostly due to the subclass having to do the palette mapping work - from an application POV reading individual frames is similarly blighted)

Somebody (Hans?) was working on a replacement animation.datatype which could support modern video formats. I'm not sure what happened with that.

chris wrote: The problem is the animation.datatype superclass is rather outdated and not terribly efficient. It needs updating to support truecolour formats ...

I think the entire datatypes system is in for a revamp. For instance, it would be great to have a document.datatype superclass that would display text document files with basic formatting and text styles. And of course, more documentation for developers would be nice to have.

@Mrup

I can confirm both your "grave" bugs.


I've posted the close link bug against amigaguide datatype bug #7132.

I've posted the resize image bug as bug #7133

trixie wrote: I think the entire datatypes system is in for a revamp. For instance, it would be great to have a document.datatype superclass that would display text document files with basic formatting and text styles.

I believe the existing one is already capable of this, otherwise AmigaGuide documents wouldn't have any formatting and the SimpleHTML datatype wouldn't have been possible.

Unfortunately even the IFF FTXT datatype is a subclass of text.datatype rather than document.datatype, so it doesn't have any formatting. If it were a subclass of document.datatype that would probably break text copy/paste for some programs. Perhaps the text.datatype superclass needs updating to support general ESC-sequence styles, such as bold, italics and various colours?

@mrupp

Using an identical config as yours i have the same behaviour here (your bug 1) if i resize the MultiView with an image it freeze instantanely, maybe it's a similar bug of this:

http://forum.hyperion-entertainment.biz ... f=14&t=163

broadblues wrote:@Mrup
I can confirm both your "grave" bugs.

@broadblues

Thanks for posting the grave bugs. But what about the minor one? Couldn't you reproduce this one, too? Would a screenshot help? Here it is: