If you have anything to add, please email me.
Synopsis: If you view a number of images concurrently (usually five),
FYEO2 will crash with two errors (when JPEG decoding, at least).
The first will be "Unexpected EOF in JPEG file", followed by an
internal error (abort on data transfer).
Proposition: If you quickly toggle the image windows full size, the one that
will fail contains a few rows of pixels, usually near the bottom
of the image. When decoding reaches this point - boom!
This points to some memory being incorrectly allocated.
Historical: A similar problem existed with the older version 2.05 though not
in the same form; however after ~5 images it would complain
about running out of WimpSlot, and crash.
Solution: Given the 'historical' message, I have increased the WimpSlot to
320K (from 256K). I do not consider this bug to be fully 'fixed'
as whatever memory allocator is failing SHOULD detect when the
application runs out on memory...
...I suspect that this is related to the intermixed calls to
malloc() while flex allocations are active, hence clashes over
who belongs where.
However I have just viewed 108 JPEGs (from my website directory)
using the same FYEO2 and no corruption or crashes...
Synopsis: If you open the iconbar menu, then the "Dithering" menu will
behave like the iconbar menu (which can be pretty weird to see).
Proposition: I think this is due to a tiny difference between the RISC_OSLib
that was originally used, and the 26/32 neutral one, which
doesn't appear to export one of it's internal variables that
FYEO2 uses.
Workaround: Open the preferences window by clicking SELECT on the iconbar
icon; DO NOT use the iconbar menu, except to Quit (unless you
will not need to alter the dithering).
Synopsis: Some 4bpp BMPs fail to decode, the output gets all screwed up.
Proposition: Most likely my maths in the bit shifting. I will look into this,
obviously, and I would appreciate SMALL examples that exhibit
this behaviour.
The same goes for 1bpp, 8bpp, and 24bpp; though I'm fairly
confident that 8bpp and 24bpp work 'just fine'.
Workaround: None. If you can send me SMALL examples (say, under 12K unless
otherwise arranged with me), then I'll have more to go on.
Synopsis: When reading a JPEG on a corrupted disc, as the corruption
is encountered, FYEO2 fails with the error:
Internal error, no stack for trap handler:
Internal error, abort on data transfer at &xxxxxxxx,
pc = xxxxxxxx: registers at xxxxxxxx.
Proposition: I tried inserting specific signal handling, and also tried to
trap the file read where the error occurs; neither had any
effect.
I suspect that this goes back to something earlier (and possibly
deep within the JPEG code). A truncated JPEG does not cause this
problem to occur (an EOF is not an error, just a condition),
while an actual disc read error (an OS error) is likely to cause
things to be handled differently.
It is also interesting to see the double error message...
Workaround: None. Given that this error occurs due to a corrupted JPEG file,
I suspect you'll have more important things to worry about. :-(
Synopsis: FYEO2 fails to render, aborting with the error message:
"Bad parameters to get_mode_from_specs"
Proposition: Possibly an incompatibility with calls to work out the screen
dimensions, which are not compatible with the non-VIDC
hardware in the Iyonix (James has an Nvidia GeForce 2).
FYEO2, currently, only handles a 'standard' selection of DPI and BPP
types, and it may be that RISC OS 5 offers more that FYEO2 simply
does not recognise.
Can people with FYEO2 and an Iyonix please run the program below and
tell me what the results are (unless every Iyonix has the Nvidia
GeForce 2 installed...?).
REM >Get mode dimensions
REM
SYS &35, -1, 4 TO ,, xeig%
SYS &35, -1, 5 TO ,, yeig%
SYS &35, -1, 9 TO ,, bpp%
PRINT "Xdpi = " + STR$(180 / (1 << xeig%))
PRINT "Ydpi = " + STR$(180 / (1 << yeig%))
PRINT "BPP = " + STR$(1 << bpp%)
END
Workaround: Switch off "Use current mode" in the output options,
and tell FYEO2 to use a specific BPP/DPI combination.