which picture.datatype?

[Bamiga2002]

I have the P96 picture.datatype installed on my WB 3.1, it replaced the one which came with the wb-install. But there exists also other picture.datatype -versions and I'm trying to figure out which of them to use? Which is best to use on WB 3.1 and what are the differences?

[Bamiga2002]

No answer eh? Well the P96 picture.datatype seems to work a treat so no answer required :-)

[thomas]

I wasn't aware that there are multiple choices. IMHO you are quite limited with your choices:

- V40 -> comes with AmigaOS 3.1
- V42 -> third party patch which might or might not be compatible
- V43 -> needed for RTG
- V44/45 -> comes with AmigaOS 3.5/3.9

So with 3.1+RTG you need to use V43 and with 3.9 you should use the one which comes with the OS.

[Bamiga2002]

Thanks I'll stick with the v43 that I have now.

[clauddio]

the v43 picture datatype from p96 works fine but the v45 from OS3.9 is faster

[dannyp1]

Has anyone tried the v45 from OS3.9 with WB 3.1?

[Bamiga2002]

I'm testing it now to see if there's any real life difference.

[thomas]

If you mix 3.1 with 3.9 components you can as well install 3.9 completely.

[Bamiga2002]

I have'em both installed, trying not to mix too many 3.9 things into 3.1

[daxb]

I use picture.datatype 44.19 on OS3.1 but I`ve mixed some more like datatypes.library 45.4, setpatch 43.7, FastIPrefs 40.35. But as you said don`t mix too much because that could introduce strange behaviours/bugs.

[Bamiga2002]

There can be dependencies that you don't know of and this mixing can f*ckup the functioning of your WB-setup. So go easy on any "borrowing" of components from OS3.9-side

[matthey]

Originally Posted by clauddio

the v43 picture datatype from p96 works fine but the v45 from OS3.9 is faster

That depends. I can believe that the algorithm and updated interface are faster for RTG in the 3.9 picture.datatype BUT it's a fat binary (68k+PPC) that takes longer to load (and more memory) and it contains trapped 64 bit integer math instructions if using a 68060. The last AmigaOS 3.5 version of picture.datatype is not a fat binary but there has been some important bug fixes since then.

I recommend ThoR's mu 68060.library if using the AmigaOS 3.9 picture.datatype with a 68060 as it's trapped instructions are significantly faster than other 68060.librarys for integer 32*32=64 which is the most common trapped instruction (used for integer division by a constant also).

[prowler]

Originally Posted by matthey

...it's a fat binary (68k+PPC)

Thanks for solving a long-standing mystery for me, matthey!

(I've often wondered what it meant when downloading files for use with my various Macs. )

[matthey]

@prowler
You could have used wiki...

http://en.wikipedia.org/wiki/Fat_binary

but always happy to help someone .

[clauddio]

here are 2 test as you can see picture datatype from OS3.9 bb2 is faster


loading big jpg file using multiview on workbench on my A1200 AGA only

picture datatype v43.41 (p96) = 30 seconds

picture datatype v45.15 = 27 seconds

***************************

loading a smaller jpg file using multiview

picture datatype v43.41 (p96) = 14 seconds

picture datatype v45.15 = 12 seconds

[Bamiga2002]

OK good , now how about the OS 3.5 version?

[clauddio]

Originally Posted by Bamiga2002

OK good , now how about the OS 3.5 version?

tested it long time ago and was faster than v43
however I'm not sure if is faster or slower than v45....I calculate are idem
if anyone can upload it to the zone I can make a cup of tests

[Bamiga2002]

C'mon someone up the requested picture.datatype so that we can get some more speed results . I don't have 3.5 installed so can't upload it right now.

[matthey]

@clauddio
Why didn't you test the newest picture.datatype 45.17 (89440 bytes)? What CPU were your tests?

I'll Zone the 2 interesting picture.datatype versions but it looks like the AmigaOS 3.5 picture.datatype has more bugs, less features and is likely slower by looking at the release notes. Here is the release notes (missing newest)...

picture.datatype 44.19 (1.10.99)

- When reading grey scale data from a palette mapped picture with
the PDTM_READPIXELARRAY method, picture.datatype now performs
a colour conversion to yield real grey scale data instead of
returning the original data "as is" [Allan Odgaard].

picture.datatype 45.4 (18.10.00)

- Made a fat-binary for PPC-support.

picture.datatype 45.6 (24.10.00)

- Added new method PDTM_SCALE to scale the pixel data to a new
size. PDTM_SCALE can only be called between OM_NEW and the first
GM_LAYOUT.
The new attribute PDTA_ScaleQuality can be set to 0 for bad quality
and high speed or any other value for good quality and low speed.

- Introduced the environment variable PICTUREDTNOPPC for test purposes.
If it is set to 1, the PPC won't be used for any operation.

picture.datatype 45.7 (02.11.00)

- Again works, if cybergraphics.library is not available (lost in 45.4).

- The powerpc.library will now be opened just before the first ppc-code
is called (i.e. no longer in LibOpen()). This became necessary, because
some subclasses open the picture.datatype within their LibInit()-
function (i.e. in ramlib context). Opening the powerpc.library in ramlib
context seems to be a bad idea, besides the stack topic.

--- changes done by stephanr ---

picture.datatype 45.8 (20.04.01)

- remapping didn't work correctly for pictures using less colors than
defined by their colormap.

- saving the selected part of a picture object didn't work because
the wrong modulo was used when the imagedata didn't came from a
bitmap.

- changed some SetSignal(0,0) to SetSignalPPC(0,0) because WarpUP allows
to check for SIGBREAKF_CTRL_C via the mirror function (this is internally
done by WarpUp by patching exec.library/Signal).

picture.datatype 45.9 (01.05.01)

- dithering an image down to 8bit works faster on the PPC, now (less
context-switches).

- remapping of palettemapped imagedata (<= 8bit) will be done by the PPC,
if available.

- reintroduced the environment variable classes/datatypes/picture/DitherHiColour.
If it is set to 0, it'll disable dithering of 24bit images on 15/16 bit screens.

- the memory for the imagedata was cleared via memset(), that was a bit slow...

- all memory that could be write-accessed by the ppc is now properly aligned
to 32byte boundary.

picture.datatype 45.10 (28.06.01)

- PDTA_DestMode defaults to PMODE_V42, now. This should fix problems with
applications that can't handle non-planar/foreign bitmaps (eg FW97).
Introduced the env variable "classes/datatypes/picture/ForceV43" for
test purposes. If it is set to 0, PDTA_DestMode will default to PMODE_V43
again.

picture.datatype 45.11 (??.07.01)

- posted to the OS3.9ß betalist by accident.

picture.datatype 45.12 (11.07.01)

- recompiled the whole datatype this seems to fix Sinans problem of
getting corrupted images.

- just for testing purpose the datatype has an internal list of all programs
that support PMODE_V43 even though they don't request this mode
(MultiView, IPrefs, AmigaGuide, WBStartup++).

--- end of stephanr's log ---

[Bamiga2002]

Thanks for information. Latest OS 3.9 picture.datatype seems to work good so I'll stick to that .

@daxb
I think the files you mentioned go OK on a WB 3.1 setup. Setpatch 43.7 is meant for 3.1 and FastIPrefs also.

slightly offtopic:
Is there an alternative WBPattern prefs program for 3.1 that includes working "center" or "stretch-to-fit" feature (without tile)? Now I can't use a small pic because the prefs force it to tile-mode. On 3.9 this is solved but can't use its WBPattern prefs (requires resource.library+).